Monday Feb 18, 2013

Blueprints for your Enterprise Private Cloud

Last week, Oracle introduced Cloud blueprints for enterprise private clouds and posted information of about it at Oracle Technology Network. The Cloud blueprints are used to describe a desired set of inter-related cloud resources.

Like architectural blueprints, for example, more than a century old blueprint , Waldhaus Gasterntal Plan5 , they describe what you want including how they are configured to interact with each other, but not how to build them. For instance, a blueprint doesn’t describe the order in which to create the components; rather, the blueprint orchestration logic figures that out based on inter-resource dependencies.

For example, in order to create a set private cloud resources, such as a WebLogic server instance, an application and a database, that interact with each other, you must first create the database and WebLogic server instance, deploy the application, and create a JEE data source that is to be used by the WebLogic server to connect to the database.

You could always perform all these operations manually, through the Oracle Enterprise Manager Cloud Self Service Portal. You would request creation of the WLS server and database and wait for either to complete. Periodically, you would check the status of the creation requests. Once the WLS server is created, you could deploy the application. When both the WLS server and database are created, you could create the JEE data source.

Alternatively, you can use a blueprint that describes the four cloud resources to automate the process. You request instantiation of the blueprint and provide any input parameter values required by the blueprint. The blueprint initiates the creation of the resources and monitors the creation process to ensure that the dependent resources are automatically created as soon as the required resources are created.

A blueprint can be used to automate the creation of cloud service instances. An Oracle Enterprise Manager self-service portal user can use blueprints for various reasons:

• To create an application composed of several service instances and related cloud resources.

• To create such sets several times (possibly with small variations).

• To facilitate instance creation for other self-service portal users.

• To eliminate the manual interactive steps that would otherwise be needed to create the set of instances

• You want a textual representation, e.g. to place it under version control or so that you can give it to someone else in a form he can review and modify.

For example, the Quality Assurance team in an enterprise needs to allocate and release resources required to test a Web application. Instead of manually creating the service instances using the Enterprise Manager Cloud Self Service application, a blueprint can be used to perform this task. One person authors a blueprint so that all QA engineers can simply invoke the blueprint and enter a few input parameter values, after which the resources are created. Each user can watch as the blueprint processor displays the status for creation of each resource.

Another example illustrates a blueprint’s use to address simplicity and consistency concerns. An IT shop has a service template that accepts 8 input parameters. For a specific group of users, the same set of values should be used for 6 of those 8 parameters. A simple blueprint accepts 2 parameters and uses the template to instantiate the instances with the other 6 parameters consistently defined.

The zipped package on cloud blueprints posted on Oracle Technology Network   has the documentation and source code to discover how to use and how to create your own cloud blueprints. The overview document introduces the blueprint concepts including how to deploy an existing blueprint as well as how to write your own. The reference manual goes into much greater detail on blueprints. 

Thursday Jan 03, 2013

Key Principles of Cloud Chargeback System

Contributed by Eric Tran-Le, VP, Product Management, Oracle Enterprise Manager

With public clouds users can now compare compute pricing pretty much like they would compare a car models. One could argue that compute power and services are different than a car but the fact is that users can compare costs.

Nothing has changed and everything has changed

Cost wise nothing has changed in a sense that the decision to implement a private cloud versus hosting on a public cloud is driven by the same factors than outsourcing or on-premise. It goes well beyond simple cost comparisons to touch upon key principles such as:

- Control of costs
- Visibility of costs
- Fairness of costs

Everything has changed in a sense that there is now a cost “predictability” expectation from users derived from a notion of “unit of compute” (the equivalent of standard energy Unit of Work) from which you can predict your resources consumption and infer total costs (a 45mpg rating means that you can drive 450 miles with 10 gallons or $40 if $4 per gallon). This is a more fundamental change in a sense that IT needs to work with the finance department to rationalize the cost-of-compute(Infrastructure + SW platform) and link it to the cost-to-serve (incident, problem, change & configuration management), the end goal is to produce a standard unit of compute that can be applied to various products and services configurations.

In part 1 of this blog, we will highlight how a cloud chargeback system can help addressing the key principles mentioned above and in part 2 we talk about how to create a profitable cost recovery model.

Key Principles of Chargeback System

Control of Costs

What is not defined cannot be controlled”, “What is not controlled cannot be measured”, “What is not measured cannot be charged”.
A cloud chargeback system provides a framework by which you can define a standard unit of cost for products and services. You can set unit of costs for resources based on hardware tiers or database high availability tiers, you can add fixed costs for on-going support costs or for facilities driven cost such as real-estate, power, HVAC,… but more importantly you can organized them by business units and cost centers so that you do have a cost structure hierarchy to report in aggregate or by business units. To define the right set of configurations, you need to baseline the current workloads utilization, characterize the patterns group of users and type of workloads and since you will use based compute metrics (CPU, memory, I/O,…) to measure utilization it is important for you to define which layers of computing ( Servers, Middleware, Databases,…) will reflect fairly the actual usage pattern of an application.

Visibility of Costs

Among all the features showing business units their VM consumption and allocations is the one that will start to change the relationship between IT and users more fundamentally. Actual utilization rate, historical trending, heat map displaying under and over utilized servers but also virtual environment configuration attributes such as high availability and regulatory compliance reports will contribute to a better cost-to-serve transparency. Another important capability to look for is how you can identify servers that cannot be part of a shared pool of resources due either to legacy applications or simply very high workload requiring dedicated machine this will help when you start sharing with the user the calculation of his charge plan.

Fairness of Costs

This the ONE difference with traditional chargeback models in a sense that metrics collected for charge calculation are actually “IT compute metrics” on top of which you add “services fee-based” metrics. In traditional chargeback direct or indirect model, the finance department tends to use non IT metrics such as # of users in a business unit as a % of aggregate IT costs or data center space taken by rack of servers,…this has led to a lot to the lack of transparency and the sense of “unfair” chargeback. As part of the charge plan calculation the characterization of fixed versus variable costs is essential to calculate the unit of charge.


Remember that in the cloud, users do not want to pay for resources they do not use and there is an expectation that they can dynamically request more resources, allocate and de-allocate resources. A cloud chargeback system will help you transition to a usage-based pricing of your IT resources will the key principles of control, visibility and fairness of costs. Last but not least, you do not need to go for the big-bang and turn chargeback right away you can implement showback and specific chargeback initiatives so that the business units can work with you on an efficient chargeback model.

Wednesday Nov 14, 2012

Slap the App on the VM for every private cloud solution! Really ?

One of the key attractions of the general session "Managing Enterprise Private Cloud" at Oracle OpenWorld 2012 was an interactive role play depicting how to address some of the key challenges of planning, deploying and managing an enterprise private cloud. It was a face-off between Don DeVM, IT manager at a fictitious enterprise 'Vulcan' and Ed Muntz, the Enterprise Manager hero .


Don DeVM is really excited about the efficiency and cost savings from virtualization. The success he enjoyed from the infrastructure virtualization made him believe that for all cloud service delivery models ( database, testing or applications as-a-service ), he has a single solution - slap the app on the VM and here you go .

However, Ed Muntz believes in delivering cloud services that allows the business units and enterprise users to manage the complete lifecycle of the cloud services they are providing, for example, setting up cloud, provisioning it to users through a self-service portal ,  managing and tuning the performance, monitoring and applying patches for database or applications.

Watch the video of the face-off , see how Don and Ed address s
ome of the key challenges of planning, deploying and managing an enterprise private cloud and be the judge !


"Zero to Cloud" Blog is dedicated to Enterprise Private Cloud Solution.
Zero To Cloud Resource Page


« July 2016