Migration to cloud has led a way to heavily automate the deployment process. Teams rely on deployment automation for not just deploying regular updates to their application, but the underlying cloud infrastructure as well. There are various deployment tools available in the market to set up pipelines for almost everything that we could think of. Faster delivery, less manual efforts, and easier rollbacks are now driving the agenda for Zero Touch Deployments.
What does Zero Touch in Cloud mean?
We would love a cloud environment where workload AWS accounts especially a production account require no console login to design, implement and operate the infrastructure and application resources. The team could have read access to view the resources but that’s as far as they can go. This helps in avoiding human errors such as forgetting to check the resource ARN before modifying/ deleting the resource on AWS CLI command. This happens with a lot of developers. Resolving these issues is what is the idea behind Zero Touch. Using pipelines and IaC (Infra As Code) tools, it becomes easier to apply it practically.
In picture (a), the IAM role “Shared-Deployment-Role” in the “Shared Deployment” account is assuming IAM roles in the workload accounts to deploy resources. The workload accounts could have additional roles to allow users to assume and login into a specific account. Users may have read-only access in Prod account to view services and resources. The “Deployment-Role” in each workload account is created along with the initial infrastructure layer using the IaC tool (AWS CloudFormation/ Terraform/ AWS CDK) and Pipelines (CodePipeline/ GitLab/ Jenkins/ BitBucket). AWS CodePipeline is configured in the Shared Deployment account and IaC templates are stored in the AWS CodeCommit repository for version control.
Picture (b) gives a high-level understanding of hoe Application deployment and Infrastructure deployment pipelines would look in AWS Cloud.
Infrastructure Layer:
Using CloudFormation templates, CodeBuild and CodePipeline; we deploy resources like and are not limited to IAM roles for deployment, VPC, Subnets, Transit Gateway/ Attachments, and Route53 hosted zone(s). These services and resources are necessary to deploy and launch the application. The resource ID/ ARN values are stored in Parameter Store for consumption by IaC templates for the application. Parameter Store helps in developing re-usable IaC templates. How? The answer is to create Parameter Store keys with the same name across all the workload accounts and allow Infrastructure templates to update the values dynamically. Deployment of the infrastructure layer is generally managed by the organization’s IT team with approved AWS services and the organization’s cloud best practices.
Application Layer:
Every application in an organization can differ in the services required to host it in the cloud. Application developers or DevOps teams can choose any one or combination of approved CI/CD and IaC tools to design and host the application in workload accounts. Teams can leverage CodePipeline, CodeBuild, CodeDeploy in Shared Deployment account to build and deploy applications in workload accounts by assuming respective “Deployment” roles. Remember that the IT team had created parameters that hold resource id(s)/ ARN(s) of resources that could be consumed by application templates. The Agile model for development, test, and deploying application templates are encouraged to be adopted ensuring only clean and tested code/template(s) go into Production.
Conclusion:
There is no one “the best” way of designing infra and application deployment. Size, complexity, cost, and time could determine what is optimal. A Zero Touch Cloud Deployment strategy can comprise various permutations and combinations of infra and application components. However, the motive behind the approach could help in minimizing human errors and many sleepless nights.
