Here’s to a Smooth App Modernisation Journey

It’s human nature to stay within our comfort zones. Yet here we are in the 21st century with an unquenchable thirst for innovation, driven by dramatic technological advancements. As the old Chinese expression goes, whether we like it or not: we are indeed living through interesting times.  

The adoption of Public Cloud infrastructures and agile, modular approaches to software development/ deployment have revolutionised IT. No longer a secondary player or cost centre, IT is expected to play a critical role in optimising business outcomes with fewer resources. Application modernisation journeys are a classic example of how IT can shine in its new role.

Rehosting, replatforming or refactoring legacy applications so they run comfortably in modern environments brings many benefits to an organisation: lower costs, better performance, faster time-to-new-features, and enhanced end-user satisfaction. IT plays a crucial role in determining which applications are best suited to modernisation and which modernisation approach is the most appropriate for each application. IT also coordinates the modernisation efforts to ensure a successful outcome.  

Here’s a typical scenario: Let’s say you’re an IT Director at a finance firm headquartered in the UK. You have a core application that could deliver more value to internal and external users if it was more flexible and deployed differently. Your IT resources are busy maintaining the infrastructure platform that currently hosts the application. There are also some office-based installs that users access remotely via VPN/RDS, which creates its own issues.  

Using this scenario as a reference, in this blog post, we present the various considerations and strategies that should be applied so that the IT Director above can achieve a successful application modernisation journey. 

Setting the Stage

Let’s start with the fact that not every legacy application needs modernising. In the context of this article, modernisation means restructuring a monolithic, client-server architecture so that the application can leverage cloud-native technologies and infrastructures. There are alternative migration approaches that do not involve modernisation, including:  

• Lifting and shifting all or part of an application to the Public Cloud This platform shift can yield limited modernisation benefits but is less likely to generate the savings expected.  

• Replacing the application entirely with a SaaS solution.  

• Rewriting the application from the ground up with modern architecture and operational processes.

Although the legacy application and the new application may run in parallel for a while, ultimately the latter will supplant the former.  

The first step in building the business case for modernisation is to determine that the effort is justified. In order to ensure buy-in down the road for the required investment and inevitable risk, all stakeholders must agree on the need and the modernisation strategy. The considerations to be applied here include:  

• Non-modernisation migration approaches such as replacement are not feasible because there is no suitable SaaS alternative. Note: Lift and shift can be a good interim migration option that takes advantage of public cloud data management resources and services while your application is being modernised (or rewritten).  

• The level of business value is high enough to justify the effort. Generally speaking, it is the core customer-facing and back-end applications that meet this criterion. Less valuable legacy applications can be left as is until retired, or perhaps even retired right away.  

• Substantial technical investment to be protected. Many legacy applications are the result of significant investment over the years in technical know-how and expertise. Throwing away this investment is wasteful and may also involve a high level of technical risk. Modernisation allows the organisation to continue leveraging its investment.   

• Cost and/ or stability reasons. Modernised applications are more resilient than monolithic ones, in large part because they take a Cattle approach versus the Pet approach of monolithic architectures. Where the Pet-based application often relies on poorly documented ‘tribal’ knowledge held by members of the development and operations teams, the Cattle-based modernised application uses identical commodity nodes that are easily spun up or down to address demand patterns. The Cattle approach often reduces operational costs as well.  

In the case of our hypothetical application described in the introduction, we are dealing with a core resource with high business value to internal and external users. It’s a bespoke application for which no SaaS replacement is readily available. The level of technical investment to date is significant and worth preserving. In short, our IT Director considers it an excellent candidate for modernisation and must now get buy-in for this decision from the various stakeholders across the organisation.  

Another aspect of optimising your application modernisation journey(s) is to evaluate how today’s software development and deployment technologies can be incorporated into or replace your current processes. Agile development methodologies, immutable artefacts under source-code control, continuous integration/continuous deployment (CI/CD) pipelines, microservice-based architectures and infrastructure-as-code are all important aspects of application modernisation.  n In our blog post Demystifying CI/CD, we discuss in depth the importance of CI/CD pipelines, which shorten time-to-value while improving code quality with their high level of automation and self-service.  

If all this sounds just a little daunting and revolutionary, our last tip is to adopt an evolutionary approach. Build a modernisation roadmap that starts with low-hanging fruit in terms of both modernisation targets and supporting methodologies. As your skills, stack and experience grow, you can begin to accelerate your modernisation efforts. 

The Role of Containerisation

Part of the transition from legacy to modern applications is shifting from a self-managed Pets approach to infrastructure resources to a fully managed Cattle approach. This can be achieved using virtual machines (VMs) under an autoscaling topology or by adopting a serverless approach. However, one of the easiest ways to implement this paradigm shift is containerisation, which abstracts the application layer from the infrastructure layer. Compared to VMs, containers are more lightweight and self-execute once triggered. Containerised apps perform well and consistently across all environments, from bare metal to private and Public Clouds. 

One of the best ways to modernise an application is to incrementally decouple functionality from the monolithic architecture and create single-function containerised microservices that are incorporated into the application logic. It is often easiest to start with middleware functions such as user authentication, transaction verification and log management.   

For example, our hypothetical fintech app uses middleware to authenticate users seeking to access the application. Instead of using HTTP calls to push and pull data between the application and the middleware, the user authentication functionality can be containerised into one or more microservices. Together, they provide end-to-end user authentication based on event triggers and API calls. The immediate advantages of this are:   

• User authentication now runs consistently across all environments from development to testing, staging and production. No more nasty surprises when moving an application into production.  

• User authentication scales up and down seamlessly, delivering a flawless user experience while optimising infrastructure usage and reducing costs. Containers are spun up and down automatically in response to traffic peaks and lows.  

• The user authentication code is now standalone. Updates or changes are carried out and tested in a separate sub-branch and merged back into the main branch without worrying about unforeseen effects on the application as a whole.   

Another advantage of modernising an application through containerisation is that container orchestration platforms, such as Kubernetes, consolidate and thus simplify container-related operations like logging, monitoring and Identity and Access Management (IAM).

Transformation as a Service

Ekco approaches application modernisation as a transformation journey. We provide the expertise and platform to bridge the gaps between legacy applications and infrastructure solutions. The end goal is a modern application that fully benefits from cloud flexibility, agility, scalability, and cost-efficiency.

 A typical journey looks something like this:

• Step 1: Deliver a cloud-like experience  

At this stage, we stream the legacy application to the end-user via the cloud, using VMware Horizon, RDS or something similar. Although no modernisation per se has taken place, this step already makes the legacy application available to a larger and more diverse user base without additional investment in on-prem infrastructure.  

• Step 2: Choose the right modernisation approach   

At this stage, we work with the client to choose the optimal modernisation approach. Can the application be refactored or does it need to be rebuilt? Can refactoring be an interim step to achieving greater benefit from the cloud while the application is being rebuilt as cloud-native? While this is mainly the client’s decision, we make sure that the roadmap supports their long-term requirements and objectives.  

• Step 3: Containerise the new app   

At this stage, the app undergoing modernisation is containerised and run on Kubernetes on our Private Cloud platform—a safe environment to continue the modernisation process, with frequent iterations over the course of the project.    

Using our Private Cloud as a modernisation hub is an important step that makes it easier to eventually migrate the modernised application to one of the public cloud hypervisors.   

• Step 4: Make it cloud-native   

In addition to moving the modernised application to the public cloud, in this step, we help the client build out a CI/CD pipeline for reliable, fast, and automated deployments.  

• Step 5: Support future ambitions   

All previous steps have ensured that the modernised application is aligned with the client’s long-term cloud roadmap. But there is always more you can do (and we can help with): continue modernising additional applications, make the deployment process even faster, start incorporating serverless functions into the application architecture, and more.   

Conclusion

A proper application modernisation roadmap starts with a thorough assessment of which legacy applications should be modernised and why. Although this process is led by the IT team, it should include input from a range of stakeholders. From business unit managers to sales and marketing.   

Ultimately, the roadmap must present a clear business case that justifies the modernisation investment both in terms of resources and risk: The application will be more resilient, it will deliver an enhanced user experience, it will reduce operational costs, it will support agile CI/CD pipelines and so on.  

The roadmap should also outline the development and deployment best practices that the company must adopt to get the full benefit from its evolving cloud strategy. In general, the organisation’s modernisation journey should be seen as incremental, starting with low-risk steps and moving gradually towards cloud-native maturity.   

Leveraging the experience and expertise of others is always a wise approach when embracing a significant change. Ekco has been the application modernisation partner for a range of companies, all at different stages of cloud adoption. We help to shrink their learning curves and reduce unnecessary risk.   

Contact us today to learn how we can help you deliver a smooth application modernisation journey.