ARDEN – The Perfect Platform to Leverage Cloud Innovation while Mitigating Risks

The scenario

As we all know, there are multiple benefits from using public or hybrid cloud – innovation, automation and resilience are three simple examples. However, moving to cloud also can involve certain risks and business disruption and this needs to mitigated as far as possible. It is with this balance in mind that

Trustmarque began the move towards a Cloud Delivery Platform that would allow us to automate and standardise our deployments as far as possible to minimise business disruption and risk, while making as easy as possible for Trustmarque and our customers and partners to leverage the many benefits of public and hybrid cloud, such as those mentioned above.

The Challenge

The key difference between an organisation such as Trustmarque and many of our customers is that we carry out multiple migration and modernisation projects a month, as opposed to our customers who possibly do this on a far less frequent basis. We wanted to answer a few key questions.

1. How could we deploy cloud resources for our customers in a standardised and automated manner, that minimised the chances of human error?
2. How could we make it as easy as possible for our customers to keep using best practice without constant consultation from Trustmarque – that is how could we make it easer for them to keep leveraging the benefits of cloud (automation, time to value for example) while mitigation risk by following best practice?

The solution

As early as 2019, Trustmarque began the journey of developing its own Cloud Delivery Platform. The first two attempts were based on a combination of PowerShell and Azure Resource Manager (ARM).

The philosophy behind these innovations was based around the following:

1. Resources in cloud would be deployed using ARM templates. These templates could be pre-built or downloaded from multiple sources such as public Git and Github libraries. ARM templates could have code that deployed entire environments that included networks, route tables, virtual machines, PaaS (Platform-as-a-Service) databases among other resources. Compare the effort of running some PowerShell Code to initiate such a template with racking and stacking servers and switches, getting operating systems on to servers and setting up routing, firewalls, backup. In and on premises environment this could take days, weeks or even months. Using code this could be done in hours.
2. All templates and PowerShell Scripts would be placed in repositories with strict governance so that nothing could be changed in an ad-hoc manner. This meant that all code was tested and we at Trustmarque knew that it worked and therefore would be reliable for smooth deployments.
3. Branching strategies would be used if changes were required. This means that Platform managers would have to sign off on any code or template changes, ensuring that these were tested before importing into the main code repository.
4. We wanted deployment code and resources that we could also share with customers so that they could use these for future deployments. This would ensure that they would be able to adhere to best practice when we handed over to them to manage as part of their business as usual (BAU) processes.

While the PowerShell and ARM based platforms were used successfully for 18 months, what became apparent was that there were more mature frameworks and tools available in the Infrastructure-as-code (IaC) space.

Terraform, from Hashicorp had enormous traction in the market and seemed to be a technology that many cloud engineers were adopting. Microsoft had released their own flavour of a declarative IaC tool called Bicep.

Trustmarque investigated both technologies, but ultimately, the fact that Terraform could be used for multicloud deployments gave us more flexibility around long term plans we have for being cloud agnostic.

Our Terraform based platform has now been tested and used for several customer deployments. We have called it ‘ARDEN’ – Azure Resource Deployment Engine. It has been designed and built in a modular fashion so that resources can be added to deployments as appropriate.

For example, we have a library of modules that allow us to deploy many different databases – MySQL, PostgreSQL and MariaDB, among others. By selecting the appropriate module during a customer deployment, we can ensure that the deployment is tailored to the customer’s specific needs, while still allowing us to use a standardised code base and standard deployment procedures.

Managed Services

We will share the code with our managed services teams and managed services customers. This will ensure that best practice is followed across all three groups.

By getting the ARDEN platform into a workflow along with our ITSM system, we will be able to provide a better service to our managed services customers.

For example, we are creating an ITSM front end that will allow customers to select VM sizes in Azure for deployment in desired configurations, into desired networks I na self service manner. The deployment of the resources will happen via the Arden Platform Modules.

The Future

By Q4 2023 we aim to start work on building and testing CI/CD pipelines to deploy the Terraform code. This would mean that we can test and deploy code as part of a continuous process using Azure DevOps.

For each new customer we would instigate a pipeline to run that would use appropriate modules, search for variable and parameter information (for example from CSV files), test the code before deployment into full production, and finally carry out a production customer deployment.

This would all be achieved in an automated manner and would make our deployments even more efficient, standardised and error free than with just the IaC elements.