In Digital Services at Blazeclan, we assist customers embarking on their Digital Transformation journeys. It’s our forté and we take pride in it! However, this brings about an interesting mix of challenges, depending upon the digital maturity of the customers, their domain, and the sector they belong to. For example, public sector customers’ usually have workloads that need to be dealt with in phases spanning over longer periods.

In this post, let’s take a look at an interesting challenge we faced and the solution we proposed to enable a public sector customer, with a bunch of legacy apps, in their journey. This public sector entity was involved in the education domain and their reach spanned in a significant geographical region. The solution that Blazeclan team proposed had to be quickly deployable, highly scalable, and non-disruptive, to the extent possible.

The challenge

The customer’s setup was composed of two main types of applications:

  1. Web applications deployed locally at each of the leaf nodes, and
  2. Windows-based thick clients deployed at few nodes.

Both of these types of applications were, however, exchanging information with each other, as well as aggregating servers — let’s call them ‘mother ships’. Since the setup was quite dated, this interaction was usually in non-real time and batch mode!

Now, the said types of applications needed to be SaaS-ified implying that they were required to be moved away from their leaf-node deployments, to the cloud as SaaS apps, with multi-tenancy support. Naturally, this move was also driven to leverage the usual tenets of cloud-based deployments – that the applications needed to be highly available and scalable (the user-base was significant) while being cost-effective. While we had dealt with the first type of applications in other transformation journeys, we were concerned about the second type of applications (2) – Windows thick-clients, that needed to be “somehow” SaaS-ified.

The solution

The whole suite of applications made us evaluate several approaches and the solution seemed to be tending towards adopting the strangler pattern.

For the first type of applications (1), one thing that worked in Blazeclan’s favour was, since they were web-based, we had the flexibility of proposing solutions that involved adding tiers (re-modularization), and/or re-platforming them to make them cloud-ready. We had heard this story before! Therefore, we proposed that a few of these applications could adopt a microservices-based architecture and take advantage of Amazon ECS. This was also beneficial as the approach had to be iterative which implied that Blazeclan team needed to facilitate quick and independent deployments with approaches like micro-frontends.

The fun part was dealing with the challenge of the second type of applications (2) where refactoring or re-platforming the application was out of scope or let’s say ‘not in immediate scope’ as they were built almost a decade ago, as thick Windows-based clients. So, SaaS-ifying these applications rather than rebuilding them was the preferred option! This was also in line with the strangler approach the team had undertaken. The Blazeclan team looked around, and that’s where