Improving Cloud Provisioning Time

Infrastructure provisioning used to be a highly manual process for Digital Service Providers (DSPs). Infrastructure engineers would rack and stack the servers and will manually configure them. Then they will install the applications over the provisioned hardware. This was a time-consuming process, with much accuracy and consistency issues. Then came the cloud computing process and it completely changed the way companies build, scale, and maintain technology products. Engineers can click a few buttons to provision servers, databases, and other infrastructure. This technological advancement improved productivity exponentially. However, the provisioning aspects of cloud remained a manual process. This results in configuration consistency issues, and the efficiency of the overall process is highly dependent on the efficiency of the infrastructure engineer/architect handling the infrastructure process.

Major challenges with manual provisioning of cloud infrastructure

• Configuration consistency
• High cost
• Limited efficiency
• Longer time in provisioning infrastructure

The above challenges can be tackled using DevOps Infrastructure as Code (IaC) methodology.

Leveraging cloud configuration orchestrator for effective implementation of DevOps Infrastructure as Code (IaC) 

DSPs need to build a cloud configuration orchestrator that contains all the infrastructure information using customizable schemas. The schemas should be editable and must contain infrastructure code, application code, and scaling policies as code.

1. Infrastructure configurations as code: The configurations of cloud infrastructure are defined in a codified way using customizable configuration files.

The below features of cloud configuration orchestrator aid in achieving efficient codification of infrastructure:

• Pre-built configuration files: The orchestrator contains pre-built configuration files for different cloud providers to provide the infrastructure. The configuration files in JSON format can be easily adapted per the chosen cloud provider and business needs.
• Execution plan- generation and preview: The orchestrator shows a preview of actions before it modifies/manipulates the infrastructure to execute the plan. This allows DevOps engineers to correct any errors that might have happened during the codification process.
• Single command decommissions: The orchestrator contains commands to decommission/destroy the infrastructure. For example, a sample QA infrastructure deployed to test the features can be destroyed using a single command.
• Multi-cloud deployment: A single script can be used to perform multi-cloud deployment, thereby mixing resources from multiple cloud vendors in a single deployment plan to build an application that is more resilient to cloud service outages.

Defining infrastructure in a codified form reduces the provisioning time by 55-60% and reduces the dependency of the cloud architect’s expertise.

1. Application configurations as code:  The configurations of the applications to be deployed on the infrastructure provisioned should be available in customizable schemas.

Key features to be built on cloud configuration orchestrator for codifying the application deployment process:

• Reusable and customizable schemas: Develop schemas to provision applications on the infrastructure commissioned. It reduces significant time compared to installing separate applications on the infrastructure. The schemas can be created in JSON format and easily reused for managing or upgrading the applications in the infrastructure.
• Grouping applications: Within orchestrator, DSPs can describe the application groups and install applications for the entire group. For example, eight app servers can be grouped, and video recording management applications can be installed on all the databases in a single go.
• Parallel provisioning of applications: Once the infrastructure is provisioned, the deployment of applications can be done in parallel with one script. This reduces a significant amount of time. Video recording management and recommendation engine can be parallelly installed across two different app servers or two groups of app servers at the same time.
• Resource schedulers: The resource grid can be used to schedule provisioning of applications during specific time frames when the expected incoming load on infrastructure is least. For example, patch upgrades for RMS application can be scheduled post the peak hours of incoming traffic to avoid any configuration drifts.
• Third-party integrations: This orchestrator can be integrated with other provisioning tools such as Chef, Ansible, Puppet, etc. for specific application provisioning.

Defining applications in a codified form reduces the total time to market by 35-40%. The benefit is further compounded as the complexity in infrastructure increases.

1. Scaling policy configurations as code: Setting up the monitoring mechanism and defining the most appropriate scaling policies is critical for efficient auto-scale implementation.

The below configuration files in cloud configuration orchestrator aid in setting up a robust step scaling policy:

• Instance launch configuration: This is a customizable configuration file that an auto-scaling group uses to launch instances.
• Auto-scaling group: Customizable configuration file to group instances. Grouping can be done based on the instance characteristics. This enables scaling policies to be applied at the group level.
• Auto-scaling policy: This contains the type of auto-scaling policy to be carried out (dynamic, step, or predictive) and the variables under each of the auto-scaling policy.

Codification of scaling policy allows the management of infrastructure without involving the console. This reduces the complexity and dependency on cloud architects. 

Sample scaling policy as code

Benefits of using Infrastructure as Code (IaC) for cloud provisioning:

With cloud configuration orchestrator in place, DSPs can realize significant benefits in provisioning and managing infrastructure such as:

1. Time taken: Reduction in infrastructure provisioning time by 65%
2. Configuration consistency: Improved configuration consistency by 27%
3. Lead time:  Reduction in total lead time by 58%

By Deepak Jayagopal