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:
- Web applications deployed locally at each of the leaf nodes, and
- 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 Amazon AppStream 2.0 came into the picture!
What is Amazon AppStream 2.0?
It’s a fully managed service from Amazon that delivers streaming desktop apps to a variety of devices. This, while being secure as well as scalable, delivers a lucid and responsive end-user experience, as the hardware can be chosen based on specific use-cases. For example, a GPU-backed VM can be chosen for streaming a 3D-intensive application. Moreover, the streaming is adaptive, based on the network conditions.
A few of the features of AppStream 2.0 are:
- Support for several target OSs and devices
- Security of streaming apps as well as the data-at-rest
- Scalability
- Cost-effectiveness
For our proposed solution, each of these had a vital role to play. Let’s see how:
- Multiple target OSs and devices support implied that the end-user did not have to rely on any specific OS (erstwhile Windows) to be able to use the application. Moreover, since the new solution needed to work on smart-devices of the present day, the OOTB support came in handy.
- Data-at-rest, as well as application security, were primary goals for us as it is with any public-facing application of today. The requirement was even more underlined owing to the fact that a few of these thick clients were finance apps which came with their baggage of compliance requirements.
- Since the user base was significant and each was supposed to use the new SaaS-ified app, as opposed to their local deployments, the scalability aspect had a high potential utility. This meant scaling-in when in the off-peak hours and hence, contributing to the next point of cost-effectiveness.
- Due to the departure from both hardware and software constraints, specific software and hardware was no longer a necessity. This resulted in us proposing more economical options for both, thus, projecting a significant reduction in the IT management costs at each of the leaf nodes.
The customers liked what the Blazeclan team proposed because the proposed solution put emphasis on minimal business disruption and seamless and smoother experience for the end-user as they would ultimately be interacting with the applications they’re used to, though via a browser. Moreover, strict security checks at each stage (VPC, NAT, Security Groups, and User Pool) helped us project how the compliance requirements would be catered to.
If we extrapolate the above, it’s easy to imagine how this reflects a totally new business model! By being able to stream legacy thick clients in a managed fashion, the customers now no longer have to worry about maintaining the latest and greatest hardware, especially for a resource-intensive app. They can just create a streaming image with their application bundled and choose to deliver it via any modern web browser. There could be multiple use cases where this could be utilized, for example, for ISVs to invite users for demos, trials, etc. of their apps.
Conclusion
Amazon AppStream 2.0 based solution helped us propose a solution that could leverage the best of both worlds: firstly, by demonstrating how a legacy thick-client can be SaaS-ified quickly, and secondly, by making use of the AWS infrastructure which is relied upon by most of the security-conscious organizations of today!
