The Client
Large Financial Organization
Business Challenge
To service their global customer base, our client had to customize each site environment. Each site must have secure federated data access. At any given time, a site user requires high capacity VMs to fulfill client and backend application requests. Besides customer needs, our client must provide demo site environments to their company team members, and also provision QA environments that match the production site fidelity for their onshore and offshore development teams in USA, India, and Europe to develop and test site changes. Bank needed an integrated orchestration platform to service the unique constraints of all their customer, demo, and QA site environments:
- Self-service: Client wanted a process that would service ad hoc automated resource requests from customers, demo, and QA users in different time zones and geographies.
- Integrated APIs: To scale operations in each site and manage a complex ecosystem of tools from a single place, they wanted an integrated platform with rich APIs. This platform should integrate with AWS, their cloud provider, as well as other complex tools and Private Cloud in their site environment setup:
- Integrate with AWS where they host their workloads
- Integrate and register VMs into AWS ELB pools
- Integrate with chosen tool to run the configuration management tasks
- Spin up and shut down AWS Docker containers that host the application stack
Our Solution
Responsible IT team serves highly customized VMs on-demand for internal and external customers, demo users, and the QA staff. All of whom are spread across geographies and multiple time zones. Needed an easy self-service catalog for demo and QA users to spin up site environments on demand.
Based on implemented solution, client can just give a set of people role-based access to the sites in Cloud App Manager without giving direct SSH permission. The Cloud App Manager web UI is easy to ramp up and add users. Demo and QA users can simply log in and self-serve environments at the click of a button.
ESP implemented chosen Cloud App Manager to integrate with a complex ecosystem and orchestrate site deployments automatically. Each site environment has a Tomcat application and web server, an NFS file server, and a MySQL database. All these servers run in AWS as Docker containers to fully isolate each site. Cloud App Manager bridged the gap between what was on AMI and what needed to be done to configure the machine as a fully compliant member of its pool
As of ESP provided solution clients IT teams are saving time on writing scripts and managing complex custom environment configurations for each site. Teams no longer need to maintain multiple different AMIs for each site environment. As of successful implementation, they define the site stack as boxes in Cloud App Manager. By defining the Tomcat, NFS server, MySQL, and related boxes once, client reuses the same base boxes to launch custom configured site environments for production, demo, and QA users alike.
Another important requirement from the Client was to regulate resources and save on hosting costs. But the highly computational nature of their application involving huge sets of data as well as federated site access meant that Financial Organization incurred significant costs to maintain these environments. So a system whose APIs would respond to a sophisticated decision-making engine was imperative. It would automatically spin up or shut down idle resources and environments based on live usage metrics.
Based on ESPs provided solution, client spin up and scale or shutdown resources in site environments with scripts and API integration. In any given site, the MySQL Docker instance runs scripts that monitor active site usage in the MySQL database. When usage demands more resources, the scripts trigger Cloud App Manager to launch the box defined stack onto AWS Docker environments. As soon as the machines boot up with the custom AMI, Cloud App Manager registers them in necessary tool, which configures them. Once the scripts run successfully, Cloud App Manager registers them in the right AWS Elastic load balancing pool in the right site using the configuration data from the MySQL server. When resources are idle, the scripts again trigger App Manager APIs to shut them down. If an environment is not in use for 3.5 hours, it shuts down.
Benefits
- Intuitive self-service catalog: Clients QA and demo users can self-serve environments from an intuitive Cloud App Manager web interface in minutes rather than make ad hoc requests to the operations team at odd hours given the time zone differences. This sort of self-service saves the operations team a lot of pages and on-call time that would otherwise require at least one person full-time to handle.
- Automated orchestration via APIs: Cloud Application Manager automation saves client three months of operations effort and the cost of hiring additional personnel. Due to the Cloud App Manager API integration and orchestration with AWS and their decision-making engine, they no longer need to do things manually. No more writing scripts manually to manage complex custom configuration for each customer, demo, and QA site environment.
- Easy troubleshooting: All the scripts are available to multiple permissioned users to review and figure out what went wrong. Even if something does go wrong, people other than specific tester knows where to look and fix because they’re used to serving up environments from Cloud App Manager. It can be decided who can see what cases. Access control assist in addressing security concerns in the company by controlling who can see what environments.
