Our client was an ISV with a multi-tenant IoT solution that ran exclusively in Microsoft Azure. The solution was built entirely in-house using Azure PaaS services, open-source software solutions, and containers. Software was released twice weekly using Azure ARM templates in a DevOps-savvy manner. Overall, the solution was mature and was the leading solution in the space for at least 4 years. But like similar applications, it had built up a lot of technical debt. Over the years the application architecture shifted from VMs to PaaS to Kubernetes containers, but no one took the time to refactor the existing code to keep it consistent, testable, and maintainable. With the increase in complexity came an increase in hosting costs.
More importantly, over time our client found they were losing business to competitors that offered similar solutions in Amazon Web Services (AWS). As a result, they made the determination that they needed to be multi-cloud. Unfortunately, they did not have AWS talent in-house. The ISV didn’t want to hire AWS talent and deal with two software stacks, two deployment pipelines, and double work to keep both solutions synchronized, not to mention the monitoring and alerting.
Our client turned to us to help them address some of these issues so they could remain focused on their core competencies: building a better product that delights their customer.
Sovereign Solutions was asked to provide Technical Resource Expertise to help them take their existing solution and get it ready for AWS. We began the engagement with an architectural assessment to document their existing architecture, build pipelines, and technical debt. We then worked with the client to determine what the desired end-state of the application should look like, factoring in our client’s skillsets and appetite for emerging technologies. We started with a small 2-month engagement for 2 Site Reliability Engineers to tactically eliminate the technical debt and build a solution that was easily supportable on multiple public clouds. Here is what we delivered:
- Completed Architectural Design and Review Sessions (ADRS) where we learned about the current solution, pain points, and desired future state. We reviewed our findings and recommendations with our client and came to a consensus on scope, roadmap, and timelines.
- Tactically fixed existing technical debt, helping our customer move many of their existing VMs to Kubernetes containers where it made much more sense (NGINX, OpenVPN, HAProxy). This allowed us to get rid of one build pipeline, created a simpler architecture needing one less monitoring point, and controlled costs.
- Moved from a bespoke Kubernetes deployment running in Azure to one leveraging PaaS services in both AWS (EKS) and Azure (AKS).
- Deployed the base solution on AWS to match the functional requirements of the solution running on Azure.
- Changed Terraform scripts to be multi-cloud. One set of scripts could be used to deploy infrastructure on either cloud. This was the most challenging part of the engagement since most infrastructure and PaaS offerings in Azure do not have a perfect analog in AWS.
- Migrated hand-crafted K8s deployment scripts to the Helm deployment model.
The AWS solution allowed our client to win business they were otherwise loosing to competitors having multi-cloud offerings. This was the biggest win for our client. But we also offered SRE resources that could augment our client’s staff to allow them to pay down the technical debt without diverting their resources from feature-functionality deliverables needed to keep their offering on the bleeding edge. Deployments are 50% faster with much simplified build pipelines. The hosting expenses for the solution have dropped by 20% with the elimination of VM infrastructure in favor of utilization of PaaS services and Kubernetes deployments.