VMware shows its prowess Cloning Oracle IdM

I grew up in a painting family and was raised by a father who was a skilled crafstman, an expert with a lifelong career in painting.  The thing you would expect, that our house would always have a fresh coat each season, or a fresh paint at all, is far from reality.  It’s like the saying cobblers children have no shoes.  As I grew old enough to form my own values and ideals about the future, I vowed to never let my family or my children go without shoes so to speak.  At VMware, we are pursuing the dream of IT As A Service, putting new kicks on our feet, and accelerating the use of virtualization across our own IT landscape.

And virtualize, we did.  I am involved on a crush team who’s objectives include streamlining and automating the build and refresh of environments using VMware virtualization technology, EMC SRDF and BCV technologies.  Since the very beginning Oracle IdM has ran on VMs at VMware except for RAC, but even now that is changing.   In spite of how compelling virtualization is for businesses and IT, it’s not as simple as running IdM on a VM.  Having hard-wired references to hostnames and PKI baked into a cloned copy makes “Instant On” a stretch of the imagination without taking appopriate steps to transform a cloned copy of say Production to make it operate as a completely separate and independent entity.

Cloning OID

VMware worked with some smart consultants at Identigral to create a procedure for reconfiguring a cloned instance of Oracle Internet Directory (OID) which is not exactly a supported and documented feature provided by Oracle, but is in any case effective for the purpose of rapid deployment.  This procedure gave the foundation for executing on my vision of clone automation for Oracle IdM that I shared with Identigral consultants.

Oracle’s OID Product Mgmt team reviewed the solution and suggested (as I would expect) that this is not a procedure to be used for building production instances.  Also, there is the risk that cloning OID will cause some problems with patching and upgrading.  But taking a step back and looking at why we want to rapidly build or refresh an environment in the first place, it’s for testing purposes, not to build a clean or new production environment.  So we have clearance from Oracle on OID cloning methodology, with the usual caveats.

Testing of the procedure proved its effectiveness so far in 2 of 2 exercises.  So now, we have a cloned VM, running a cloned OID, which is setting the table for either cloning OAM or installing it from scratch, or a hybrid of cloning and re-installing.

Cloning OAM

Cloning OAM is not as easy nor as straight forward of an approach.  There are certainly shortcuts for building any new OAM environment, or refreshing an environment (affecting only user data) but for a company whose ambition or need is to build numerous test instances for whatever reason, the argument for taking shortcuts and even automating to a certain extent is compelling. 

To start, as quick as it is to install new servers, and ensuring that there are no corruptions or issues when building the core configuration, the fresh install of OAM servers is a good safe bet.  Once the core foundation is installed, policies and configurations can then be exported from a source, lets say a golden copy from production, and modified to fit the needs of your target environment. 

Here is where the black art of Oracle IdM environment management comes into play.  Attempts by Oracle to offer migration tool set has not been received well, so this creates room for Oracle Consulting, and their partners to add value to IdM customers.  Typically, IdM consultants with years of experiences can have an intuitive knowledge about what should be copied from a source environment, how to massage the data, and then import it into the target environment in a manual approach spanning several days depending on the environment complexity.   This is a valuable, and critical competency that any IdM Administrator should have, and of course the organization who has OAM.  Multiply this exercise of say 40 hours by how many environments you plan to use for testing and development in the coming year and then by $125 or more, and you come up with a figure for annualized maintenance costs just for instance management.

Extreme Cloning

Taking the project to an even more extreme level, a person could justify automating the clone procedures by writing their own scripts to export, transform and deploy on the basis that the one-time development costs are less than the annualized maintenance costs.  The ROI formula I came up with looked something like this:

  • Approx. number of hours to build OAM manually = x
  • Hourly rate of IdM Admin = y
  • Number of environments you will build this year = z

With that you can come up a figure with the following formula:  Annual instance management cost = (x*y)*z

In contrast, lets say that we could develop and deploy scripts to automate a large portion of this work. 

  • Approx number of hours to design and build scripts to automate clone activity = x
  • Hourly rate of expert programmer who has 3+ IdM experience = y

Then we can perform a basic ROI measure that should allow you to calculate your break even point.  Management will need to know how many environments would need to be built in order for investment in clone automation to pay off.  Depending on how aggressive your IdM initiatives are, it may take more than a year of utilizing your new tool set to see any ROI, not to mention that there are opportunity costs that should be factored in.  (E.g. Your expert programmer is going to be taken off of some other high priority project which can be a setback.)

And to make things even more interesting, recent VMware acquisitions add even more technical capabilities that should ultimately help reduce costs and complexity of  instance management.  I’m looking forward to the assimilation of Spring Source and Ionix into VMware virtualization platform so we can create and share templates for IdM configuration management.  Imagine configurable templates as a feature of your platform that transparently supports duplicating and managing IdM environments without the risk and cost of custom software, including having all of the appropriate monitoring (E.g. Zenoss, EM grid agents) deployed right next to it.

I’d love to hear ways you use VMware to make managing and deploying Oracle IdM easier.  Leave comments here in this blog post or send an email to steve at stevetout dot com.