Continued from Part 1…
Application Setup and Deploy:
The Player exclusion spring-boot microservices will run on Docker container-based Linux instances. It will use Azure DevOps toolchain (Azure Boards, Repos, Pipelines & Artifacts) for its software development & delivery lifecycle. Azure DevOps will handle Application deployments in an automated manner to provide a streamlined error-free development lifecycle.
The Application Code will be hosted in Azure Repos. Code Check-ins trigger a Maven build in Azure DevOps which deposits the jar and library files in Azure artifacts. This would then be followed by a Docker build that containerizes and pushes the artifacts to the Azure container registry. The containers are now available to be deployed into Azure App services.
The biggest challenge we had to face during deployment was that App services were housed in an isolated App service environment due to compliance requirements. We had to create dedicated build agent pools in the management subnets (with updated hosts files) to access the environments. Once the line of sight was established, we used Azure DevOps Update WebApp jobs to deploy the latest containers to the corresponding Azure Web Apps and a good old restart.
There were some complex deployment scenarios where we had to deploy a combination of Web jobs and Containers on the same WebApp. After trying out a few different approaches, we settled on creating new Virtual Applications in the relevant Web Apps and copying the batch jobs along with its cron schedule.
Infrastructure Setup and Deploy
Infrastructure is codified in the form of Azure Resource Manager (ARM) templates deployed via Azure DevOps. The templates are maintained in a separate repository with environment-specific parameter files for isolation. This abstracts the end-user from the template and protects against accidental deletion.
The infrastructure has been logically grouped into Hub, Spoke, Storage, and WebApp resources. This simplifies the infrastructure codebase and permits individual components to be destroyed and rebuilt as needed, allowing for selective provisioning. This also facilitates infrastructure teams to modify and build new infrastructure by dealing with segments of code rather than the whole.
The infrastructure was then deployed using a series of Azure DevOps Create/Update Resource Group jobs.
The deployment job is gated with pre-deployment conditions which stops the deployment if any of the preceding tasks fail. The deployment is also user(group) restricted to so infrastructure can only be deployed by teams authorized to do so.
Now comes the usually dreaded part for any Engineer, Training!!
But circling back to the top, our decision to automate everything and use only Azure products, (where possible) exponentially cut down the client’s ramp-up time for Go-live despite being their first greenfield cloud project. It minimalized bombarding the team with excessive steps, different UIs, and switch between layouts and terminologies, easing the training process. Client Ops team was paired with our managed services team for continued assistance
Thus, we initiated our Client’s first Cloud journey. Addressing all the real-time challenges of a greenfield cloud project cannot be captured in an article series, but I have tried my best to detail out our process and execution. I hope this has given you some clarity of thought on how Cloud Project is implemented from the ground up.
If you have questions about how to start your cloud journey, and/or design, security, cost concerns involved, reach out to us. Let us help you figure out the best way forward.
Ready, Set, Cloud!
Leave a Reply