Media Center / iWave Blog

Layering Makes for Good Cakes, Cloud Automation Architectures

By Brent Rhymes

In our last blog post we talked about the different options solution providers (SP) have when considering automation technologies for their public and private clouds.  
 
Just to recap, those options are: 
 
- Cloud automation products: These provide out-of-the box functionality, fast deployment and quick learning curves for IT staff at the expense of flexibility and extendibility. Examples include vCloud Director, NewScale/Tidal, Dynamic Ops, etc. 
 
- Bespoke solutions: These consist of a combination of custom-developed scripts, software and open source tools that provide a custom automation solution that fits into SP's existing IT management processes. This option provides maximum flexibility, but it is expensive for the SP to maintain.  
 
- IT process orchestration (ITPO) products: These offer a combination of prebuilt content (adapters, workflows, etc.) and customized/bespoke workflows that model an SP's existing IT management processes. ITPO products offer the flexibility of said solutions, yet provide prebuilt content that is supported as an off-the-shelf cloud automation product. The challenge of ITPO products, however, is that they have a steep learning curve and typically initially require outside consulting . BMC Atrium Orchestrator, HP Operations Orchestrator and EMC IT Orchestrator are all examples of ITPO platforms being considered by Estes today. 
 
Regardless of which option an SP chooses, the SP will have to implement the automation solution into an architecture that can handle the underlying complexities of its existing IT infrastructure. We've observed that the most successful architectures being deployed today follow a common theme. Like a good cake (or even a good dip) cloud automation architectures are layered.  
 
The three basic cloud automation layers that we've observed include: 
 
- Service invocation layer: These automated services are invokable from multiple sources and include self-service catalogs, existing customer portals, third-party ITSM applications, etc. Typically, SPs achieve this flexibility by deploying standards-based APIs to separate the applications invoking services from the automated services themselves. Example technologies include Web services APIs, RESTful APIs, etc. 
 
- Service automation layer: Cloud service automation processes such as virtual provisioning, physical provisioning, automated workload management (cloud bursting), automated disaster recovery (cloud cover), etc. should be represented as a series of abstracted workflows that can be called from the service invocation layer. These workflows should be designed and constructed so that they can be modified and extended without requiring major changes from the applications calling them in the service invocation layer. 
 
- Service adapter layer: Finally, the software used to interface between the automated phone services and the underlying infrastructure should be abstracted into an adapter layer. This adapter layer will help insulate changes within SP's physical and virtual environment from impacting the automated cloud services. 
 
In a world where everyone wants everything to be "iPad easy", the architecture described above is complex -- but it is also honest. As those who are serious about automating the processes used to manage cloud infrastructure understand, there are no simple iPad-like answers. To quote the great Homer Simpson, "Who ever thought a nuclear reactor could be so complicated" The same can be said of underlying cloud infrastructures. SP's should seek the advice of trusted partners and vendors when building their cloud automation architectures, so that they end up with solutions that are flexible enough to manage their businesses today and powerful enough to accommodate the innovations and technologies to come.