Two approaches to Application Modernisation

We hear the term ‘application modernisation’’ used with two very different mindsets:

1. Rewriting or porting a legacy system to a modern programming language or platform (e.g. a COBOL application sitting on an on-premise, AS400 box being moved into the AWS cloud);
2. Repurposing your current application in line with your current user, market, and industry demands (e.g. enabling your suppliers, customers and staff to securely access warehouse data from any browser, anywhere in the world).

The examples we’ve given for A and B describe precisely the same project from two different perspectives: A is looking at the technology platform and code; B is looking at what matters, which is people and business.

How you view application modernisation will determine how you set goals, invest, and ultimately whether it is a successful business project or simply a project in which to pour cash.

Why modernise

Investing in app modernisation prepares your business for digital transformation, which changes the way you are able to operate and deliver goods to customers.

Most application modernisation strategies include hosting applications and data in the cloud. Companies that do not take a deeply strategic approach to app modernisation will sacrifice their competitive advantage and may find themselves attempting to modernise their legacy apps again in a few years. When planning, you should examine the environment’s structure, how you manage projects, and ensure you obtain software that will meet your specific business needs. Improved security, speed and consolidated systems are essential to succeed. 

Research by Gartner predicts that by the year 2023, as many as 40 percent of workers expect to carry out their business meetings and activities online. Workers continue to demand applications similar to those they leverage in their personal life; application modernisation makes this achievable.

The advantages of app modernisation include the following:

• Mobility enables productivity and efficiency.
• Enforced security measures.
• Application modernisation saves time and money.
• Workplaces are connected and integrated.

Break it down

Breaking down a monolith application into smaller pieces is best done with the “measure twice, cut once” mentality. Before starting, you must collect as much information as possible about the monolith. 

Your developers also need to ensure that they have someone experienced in microservice architectures and other cloud-native technologies. If your developers lack experience in these fields, then you may want to consider outsourcing the task.

Before commencing, you should ask four key questions:

1. What outcomes do you want to achieve through your app modernisation initiative?
2. Does anyone on your team have in-depth knowledge about the monolith?
3. What expertise do you developers have on the app? Were any of them in the original development team?
4. Can your developers map the app service? 

With app modernisation, you may gain more benefits by increasing your upfront investments. You should do a cost-benefit analysis to see which approach would be best for your app and which strategy will help you achieve your goals.

Depending on your series of criteria and outcomes, you can choose from three modernisation destinations:

Infrastructure automation

Also, known as cloud infrastructure ready, this particular approach is reserved for those applications which have low business value. These apps are known as sustain apps, and their primary purpose is to sustain the business rather than bring in new revenue.

Immutable infrastructure

This approach allows the monolith to leverage cloud infrastructure to up-version its components. With this method, application code can be changed, and the base platform services can feature programs such as Amazon RDS and Amazon Elasticache.

Serverless or managed infrastructure

Often called the cloud-native approach. It is ideal for monolith applications that need full modernisation. It allows you to use advanced technologies such as serverless or microservices. Developers need to refractor their services, composing the application while retaining business logic. Many benefits come with the new cloud-native application.

Code bases that split into individual services facilitate advanced automation, which increases time to market. Updates are quick and easy for customers to access, and you reduce risk factors because developers no longer need to learn the ins and outs of the monolith codebase.

Separate from infrastructure

It is not uncommon for IT and DevOps teams to handle several app modernisation projects. However, many do not understand the need to separate applications from infrastructure when modernising, which saves time and avoids vendor lock-ins. Without this method, many developers become stuck with choosing a single cloud or container vendor. Unfortunately, this often leads to price increases in the future.

Applications where custom-built unbreakable monoliths exist, such as SAP, Siebel and Oracle, are challenging to modernise because the elements that go with the apps — such as data, security and network formations — are embedded in the underlying infrastructure.

The infrastructure makes it hard to upgrade specific components individually. Even the smallest processes can take weeks. In addition to this, business units may also have legacy applications installed at different infrastructures, making it challenging for IT teams to combine and enhance their infrastructure budget for platforms that offer speed and agility.

Developers must separate enterprise applications from any underlying infrastructure. Things that can be abstracted include data, network and security features. Abstracting the functions of applications into components means that you can move applications anywhere without having to change any code. Movability is also possible through a software-defined infrastructure which allows you to compose the applications from the components.

Through separating applications from infrastructure, IT organisations can overcome vendor lock-in and gain the flexibility required to move their applications to vendors of their choosing (who offer the best price, performance and are reliable).

Prioritise security

It is essential to prioritise security and take precaution when rewriting your apps for a modern, internet connected world. Security issues found late in the development cycle can lead to compromised code and defect data.

If developers miss security features, this results in stalled benefits of the DevOps pipeline as problems need to get fixed. 

You can account for this development risk by doing the following:

• Assess the risks of any changed contexts early.
• Implement consistent automated security controls.
• Externalise policy management and credentials.
• Update the security controls for changed risk context.
• If applications move to the cloud, consider the content of that environment and the risks associated with it.

Different cloud servers provide various security features. It is vital to look into each one and see which one is the most effective for you. Any applications that your team migrates (virtual server or container-based) also need to be configured correctly with specific security features and continuous maintenance.

Traditional applications had the problem of static passwords and encryption keys that could not be changed. With the cloud, each component consists of unique passwords and ensures that the compromise of a single credential does not affect the whole platform. Security must remain consistent in the multi-cloud world to provide mobility and flexibility.

PolarSeven powering Application Modernisation

PolarSeven is an Advanced AWS Consulting Partner with DevOps competency. We help you make the right infrastructure choices for your application, provide the know-how to design and deploy it, and offer flexible managed services to keep it optimised. If you would like to learn more about how we can help modernise your applications, contact us today.