How to Leverage Automation to Accelerate and Secure Azure Infrastructure Deployment and Maintenance: Part 2
Jan 11, 2023–
Customer: Global Cosmetic Company
Project: Global S/4 system on Microsoft Azure
Technologies Used: Terraform, Ansible/AWX, Azure
Project Goal: 200+ virtual machines deployed on Azure for a Global Cosmetic Company
Looking at SAP-related VMs (virtual machines) only, we have the following:
- 50 HANA database servers
- 15 clustered environments
- 50 ABAP servers
- 15 JAVA servers
The philosophy behind using automation is based on the assumption that if a task will repeat multiple times, it makes sense to automate it to save time and human error in the future.
Using automation for deployments with infrastructure as code can be tedious, with a significant investment in time required initially. This investment is recuperated with the following benefits:
- Gain time for future similar tasks
- Guarantees homogeneous systems and configurations (no manual human mistakes leading to unexpected errors)
- Easy server maintenance through automated tasks
- Code allows better control of Azure resources compared to a manual deployment
Project Challenges and Solutions
For any project, we need to think about automation and anticipate what kind of actions would need to occur frequently. The customers might have specific tasks they want to put in place; our job is to identify which tasks can leverage automation. Thanks to automation, it is profitable for all parties to gain time and reliability. The earlier we start thinking about automation and implementing it, the sooner the benefits are realized.
Implementing automation processes when production is already running is always possible; however, it requires significant testing. Nevertheless, when this challenge is properly approached, you can safely implement automation in an existing customer landscape.
Interview Questions (Part 2)
How long was the preparation time for a project of this size, and what resources were necessary to implement it?
Jean: On oXya’s side, two people dedicated time to this customer’s project, Patrice and myself. Patrice is part of the oXya Cloud Excellence Group. He is a Microsoft Azure certified specialist with many years of experience and a significant background in customer deployments on Azure.
On my end, I have worked for over ten years with oXya as a SAP Technical Basis Expert. Since 2017 I have been part of the oXya technical expertise team, working only for our customers moving to the public cloud.
Within a few weeks, we reused and put together pieces of code used for other projects and adjusted those for our customers, which helped reduce the initial time invested in setting up automation for this project. With automation being used for almost all oXya’s customers today, this is a great benefit to bring online any automation for our customers’ needs quickly.
What is oXya’s involvement post-deployment? In terms of maintenance, what does oXya have to do? Does the client have to be trained to use the automations deployed by oXya?
Jean: In terms of automation, the customer is involved at a high level. They know we are using automation and highly encourage it. They require it at the beginning of the project, given their experience with oXya. All the automation configured is internal to oXya and not visible to the customer. The knowledge is kept internally and used to grow the automation skill sets within oXya for all our customers and teams to leverage its benefits. Given the sizable internal usage of all our automation solutions, we continue to evolve and grow our expertise by having all our administrators contribute. The collaborative environment allows us to improve our code and automated solutions based on our admin teams’ usage and feedback.
Are there any next steps in terms of automation for this client or any next steps in this project?
Jean: As this is still an ongoing project, the client constantly needs new servers, as not all regions have consolidated into the new global systems.
Every month we receive requests from the client to build new servers and onboard new regions. All these new servers need to be deployed, maintained, and patched, like the existing ones. Therefore, the two automation use cases described above are leveraged on all new deployments and environments.
What is next for this client in terms of automation?
Jean: Disaster Recovery. On Azure, we have everything built and failover ready in case of disaster, meaning everything moves from one server to another (from one region to another). We continue to conduct Disaster Recovery testing to validate and improve the Disaster Recovery configuration.
Disaster Recovery failover processes have many manual activities, and especially in a crisis, automated activities improve failover times and significantly reduce administrative errors. As a result, the Disaster Recovery solution has been identified as the next primary phase of this project.
Patrice has built the disaster recovery on Azure for this customer, along with some Ansible/AWX jobs to automate these steps. My colleague Shiming, who has led the DR exercises, is taking over this activity to incorporate these benefits into the process.
If you are interested in oXya’s approach to automation, we would love to hear from you — If you are in the US, reach out to our US-based team at firstname.lastname@example.org. If you are in the EMEA region, reach out to our headquarters team at email@example.com.