Oracle Blog

Zero to Cloud

Monday Feb 18, 2013

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.