Lessons Learned from Region buildouts:

Introduction: This article summarizes some of the lessons learned from building new region capabilities for a public cloud. Many public and private cloud providers expand their geographical presence in terms of datacenters. This is a strategic advantage for them because it draws business from the neighborhood of the new presence. A geographical presence for a public cloud is only somewhat different from that of a private cloud. A public cloud lists regions where the services it offers are hosted. A region may have three availability zones for redundancy and availability and each zone may host a variety of cloud computing resources – small or big. Each availability zone may have one or more stadium sized datacenters. When the infrastructure is established, the process of commissioning services in the new region can be referred to as buildouts. This article mentions some of the lessons learned in automating new region buildouts.

Description: First, the automation must involve context switching between the platform and the task for deploying each service to the region. The platform co-ordinates these services and must maintain an order, dependency and status during the tasks.

Second, the task of each service itself is complicated and requires definitions in terms of region-specific parameters to an otherwise region agnostic service model.

Third, the service must manifest their dependencies declaratively so that they can be validated and processed correctly. These dependencies may be between services, on external resources and the availability or event from another activity.

Fourth, the service buildouts must be retry-able on errors and exceptions otherwise the platform will require a lot of manual intervention which increase the cost

Fifth, the communication between the automated activities and manual interventions must be captured with the help of the ticket tracking or incident management system

Sixth, the workflow and the state for each activity pertaining to the task must follow standard operating procedures that are defined independent of region and available to audit

Seventh, the technologies for the platform execution and that for the deployments of the services might be different requiring consolidation and coordination between the two. In such case, the fewer the context switches between the two the better.

Eighth, the platform itself must have support for templates, event publishing and subscription, metadata store, onboarding and bootstrapping processes that can be reused.

Ninth, the platform should support parameters for enabling a region to be differentiated from others or for customer satisfaction in terms of features or services available.

Tenth, the progress for the buildout of new regions must be actively tracked with the help of tiles for individual tasks and rows per services.

Conclusion: Together, these are only some of the takeaways for a new region buildout but they show case some of the issues to be faced and their mitigations.