Application modernisation is a bit like wasabi. It’s not for everyone. However, when application modernisation is the correct remedy, it’s also a bit like wasabi: it needs to be done right, for the right reasons. And with the right architecture, though the wasabi motif falls flat right there.
That’s according to Erik Jensen, founder, global CEO and CTO of TrueMark. “The value proposition for modernisation is clear cut, but it isn’t always explained in a clear way,” he says. “It’s actually various shades of grey.”
Before getting to that, the Utah, USA-based CEO of the Advanced Tier AWS Partner is happy to explain why he’s targeting the South African market (the company has its South African headquarters in Sandton). “We went into the country for an opportunity, and subsequently saw many more,” he obliges. “We like addressing underserved markets and already have eight engineers there and a number in Europe. And I always enjoy a good accent,” Jensen quips.
Back to the business of the day. Updating legacy software to modern technology offers advantages including improved performance, scalability and the allure of cost-efficiency. It can involve moving to the cloud, adopting microservices, using new containerised architectures and agile delivery techniques. It revitalises outdated systems by enhancing their infrastructure, code and features to meet current business needs and digital demands.
Jensen says the shades of grey emerge because modernisation has nuance. “If you’re just re-hosting or re-platforming, neither involves touching the application code. It’s a lift and shift for the re-host, while a re-platform involves taking advantage of some cloud features, but without changing the application in any meaningful way.”
These projects, therefore, don’t carry a particularly strong value proposition beyond changing where the application lives. They’re also not particularly risky, beyond occasionally delivering unexpected cost escalations. (Yes, costs can and do go up, particularly if there isn’t a close eye on architecture, optimisation and taking advantage of flexibility, performance and accurately matching available services to specific requirements).
Deeper modernisations, continues Jensen, are much more involved. It’s also where TrueMark likes to play, and as a technical CEO, his eyes light up at the prospect. “This is where we get into the application code and disassemble the monolith, breaking it up and then applying native AWS services. And that can go really, really deep.”
However, while that gets the techie in him going, Jensen is quick to add that the drivers for modernisation should first be carefully considered. “Not everything needs to be modernised and it should never be done for the sake of it. Just because the technology is old, for example, doesn’t mean it isn’t good.”
Instead, it should start with a business case. Reduced maintenance costs, gaining new capabilities or features delivering market advantage, eliminating scale constraints or solving skills or security issues: these are sound justifications. “It often comes as a surprise that a simple re-host, moving the application in the AWS cloud, will cost more, not less. You’re trading capex for opex and that may well soon be higher,” Jensen points out.
“When on-premises applications restrict performance, security or business capability, only then should modernisation should be on the table. These are the prime candidates.”
He singles out security as a common driver. “I like to say data centre applications are crunchy on the outside but squishy in the centre, like a chocolate,” Jensen laughs. “That’s because they tend to have decent perimeter security, but once past that it’s easy for an attacker to move around. That’s why you keep seeing a lot of them getting bitlocked, because zero trust in these environments is both expensive and difficult.”
Noting that AWS offers somewhere in the vicinity of 240 services within its cloud, Jensen says a trusted partner is essential in navigating application modernisation projects. “How we modernise, how we structure and reconfigure the application, and where we place and schedule workloads depends on the customer, compliance requirements and other factors,” he explains. “Each one of those services is a set of knobs which, out the box, hit maybe 80% of the mark. The rest is config, and you really want people with a deep understanding. It’s crucial to success; for example, Kubernetes is really a network operating system, it’s a beast, and if you don’t have niche speciality expertise, it’s not going to deliver the value you want.”
Beyond technical expertise, he again refers to the business case. “For example, some workloads you’d want to maintain in South Africa, so we’d use the AWS Cape Town Region; if the user base was broader, we might use CloudFront to push the application to the edge. Service level and uptime agreements would determine the structure and services supporting the application, and we’d establish business continuity and disaster recover requirements. There are lots of options, all of which have cost and performance implications, which in many cases were the point of modernisation in the first instance.”
Share