Country

Sweden

Description

Our client is a growing FinTech company with the increased number of developers and projects faced inevitable struggle with monolith architecture unable to keep up with business demand from development. The application is written in .NET with some integration components in pure C#.

Challenges

+ long time-to-market due to cumbersome deployment automation that didn’t consider application growth

+ difficult onboarding process for developers: with how tight the app components are coupled, there’s no way to isolate a specific function to work on, so everybody has to learn the entire project

+ lack of documentation and awareness

+ sophisticated infrastructure that wasn’t designed for scaling but had to adapt as the application and its ecosystem grew

+ unreliable testing process: reproducing the application and infrastructure state from scratch to complete end-to-end testing took a while, while the results were mixed

+ poor observability: existing means of monitoring didn’t provide enough awareness of the state of the application, its data and infrastrucure

Solution

Corewide team performed a usual audit of the existing setup, drew a diagram of the planned setup and suggested a work scope that covered all the found issues and client’s challenges.

It was decided that DevOps effort would align with development team’s schedule on moving away from monolithic architecture to microservices – until they have, Corewide engineers work on preparing the infra for the new setup and all means of migrating the stack.

Weekly status meetings were set up between leads of both teams to track the progress. Between DevOps milestones, a demo was conducted for each. While Corewide worked on other scoped tasks, the development team was studying the documentation provided for already completed work.

+ The application was containerised already but little of the recipes could be reused with new architecture so the new custom recipes were written for each of the microservices, following the best practices in containerisation. 

+ As the client already had an existing infra in Azure and it met all of the new requirements as well, we didn’t need to change the provider. In parallel to containerisation, we approached cloud resources management with Infrastructure as Code using Terraform.

This way, all the cloud level changes became transparent, traceable and reproducible. State of Azure resources was described in the code that handles multiple environments (dev, UAT and prod) while remaining easily maintainable.

+ To address autoscaling and reliability of the applications, we decided to orchestrate the microservices by means of Kubernetes. Azure managed offering for Kubernetes (AKS) was selected, and the cluster setup was also handled via IaC.

+ A monitoring system was deployed early on to collect performance metrics and website logs: the more statistics we could get, the more accurate autoscaling parameters could be set. All data was arranged into custom dashboards that displayed vital statistics and realtime state of the cluster and applications deployed to it.

+ By the time both infra and containerisation work were complete, dev team had written the majority of the microservices. This allowed our DevOps engineers to write custom deployment packages for Kubernetes – Helm charts.

With Helm, every application with all its Kubernetes-specific resources became a coherent package in the cluster that can be managed as a single entity, parameterized and upgradable with its own versioning.

+ Completion of Helm charts opened the path for our team to write CI/CD pipelines to streamline the builds and deployments. Each pipeline ran builds, unit tests and security analysis of the code, then deployed it to the dev environment.

Once features reached enough stability they were rolled to UAT. Upon completion of automatic end-to-end testing in UAT, the deployment could be approved for rollout to production. Any failure triggered an automatic rollback to a previous version. 

+ The documentation for all the project layers (infrastructure, container recipes, Helm charts, CI/CD pipelines, security policies, disaster recovery) was shared with the client gradually as the milestones were being delivered. The diagrams of the setup created initially were updated to include changes that had been made during the implementation phase. 

Struggling to find an excellent DevOps services provider? Having custom business demands? Corewide’s got you covered! Leave us a message – we will contact you back ASAP.