Based on our practical experience, our initial modernization plan for KLER’s infrastructure revolved around decomposing the monolith we encountered at least partially into serverless functions orchestrated automatically by AWS Fargate over AWS ECS. With such an architecture we would be able to defer resource management entirely to AWS.
Not having to tackle resource isolation nor scaling – as those would be handled by AWS Fargate to fluidly meet actual compute demand in a granular manner – the burden on KLER would be drastically reduced, enabling the company to focus on its core business domain and meet its customer’s needs without having to worry about the infrastructure needed to meet those needs.
However, everything in computing is a matter of tradeoffs and no one solution meets the practical needs of everyone. In this case, while the benefits of a serverless architecture were tangible to all stakeholders, the actual implementation proved difficult performance-wise – mostly due to KLER’s existing codebase, which was not easily amenable to a serverless mindset based on decomposed microservices.
Refactoring the entire codebase was not practically feasible either – but it was also not necessary to achieve the goals we aimed for. After all, AWS catalog of managed services is extensive, and the flexibility this fact alone provides is invaluable. As any business is all too well aware of, plans must be flexible enough to adjust to any and all circumstances.
Thus, we simply slightly scaled down our proposed best case scenario and instead of AWS Fargate opted for a more traditional container based architecture running EC2 instances directly on AWS ECS.
We had to tackle the provisioning of resources after all, but still introduced a major modernization to the flow – infrastructure-as-code. Terraform helped us organize and describe KLER’s infrastructural needs, allowing the client to flexibly adjust them on the go in a centralized, coherent, versioned – and most importantly: automated – fashion.
The solution we delivered auto-scales resources based on actual compute demand and is easily amenable to both high short-term variance, as it is to long-term business growth. What’s more, it is not intrinsically bound to AWS – KLER can now opt for multi-cloud deployments, if it chooses to do so.
Both the production and development environment have AWS ECS at their core, responsible for scaling the services horizontally to keep up with demand on one hand, and on the other to guarantee their high availability. With appropriate redundancies finally in place, we further enhanced this setup with a Load Balancer, to make optimal use of all provisioned resources.
Amazon EFS was also used, which makes the data accessible across all services simultaneously – and potentially even beyond a single geographic region. Its auto-scaling characteristics further reduce the need to pre-estimate demand.
Last but not least, all production data is now finally automatically backed up as appropriate, providing an essential part of previously severely lacking durability.