One of my clients has been using CSC’s Agility Platform to orchestrate X86 workloads to private cloud and data center environments. Orchestrating to public cloud is what is being looked at next, especially AWS.
Agility is our consolidated platform for hybrid cloud management, governance and security across public and private clouds. Agility provides a cloud provider (aka adapter) to enable orchestration to public cloud, and so we developed a couple of proof of concept (PoC) solutions: DevOps and big data with workloads orchestrated through Agility.
Getting the PoCs to work gave us several useful insights, which I wanted to share through this blog.
First of all, Agility and AWS form a powerful combination (for that matter, this is true for any platform that Agility supports). In other words, Agility becomes central to the strategy for workload orchestration to private cloud, public cloud and data center X86 environments.
Careful selection and design of Agility blueprints can save a substantial amount of time. You could build one set of blueprints in Agility and orchestrate to different environments.
DevOps and big data are particularly good use cases for the AWS/Agility combination. We can spin up EC2 instances for Dev/Test whenever needed and bring them down once we are done with the Dev/Test activities, all in an automated manner, saving time and cost.
There are a few points to be kept in mind to get the AWS/Agility combination to work. Here is what Srinivas Konduru, one of the architects in my team, and myself learnt in our application:
- Cloud provider support: as of now, Agility Cloud Provider only supports provisioning of EC2 instances
- Configuration of Cloud Provider: while configuring the adapter, the security keys and hostname parameters have to be provided, which includes the region information (e.g. ec2 us-eaast-1) and the cloud url(e.g. aws.amazon.com)
- Sync with Agility: Agility synchronizes keys, VPCs, subnets, images, volumes and such information related to AWS with Agility
- Machine Image Specification: AMIs have to be configured on AWS
- Stack: a stack needs to be defined and all the AWS EC2 instance launch information has to be provided
- Blueprint: a blueprint has to be defined in Agility that references the stack with launch information for EC2 instances
It takes a little bit of time to get a hang of what all needs to be done on the AWS and Agility side (e.g. type of AMI, size etc.) but once that is done right, it feels great to see orchestration in action with AWS.
Does this resonate with what you have been doing? I would love to hear any experience and insights you may have gained in orchestrating to public/private clouds.
Shankar Kambhampaty — Distinguished Architect
Shankar Kambhampaty (Global Business Services) is a technology enthusiast, IT veteran and author who has provided application, service and system architectures to leading organizations worldwide. Currently he is CTO for a large financial services account, leading a global team of over 40 architects. He contributes to industry level initiatives and is regularly invited to speak at industry and academic conferences. He is author of the book Service Oriented Architecture for Enterprise and Cloud Applications, has written many papers on architecture, and also blogs at archtecht.com.