Refactorization of Cloud: No Magic, Hard Work, but Less Risk

Introduction

One of the common challenges that companies face when moving legacy applications to the cloud is that a simple “lift-and-shift” frequently isn’t an option. The reason why some applications can’t be migrated without modification could be that a workload assumes a specific physical infrastructure that isn’t replicable in a cloud environment.

What is refactoring in cloud migration? To refactor cloud migration is to restructure existing applications and infrastructure for optimal performance, scale, and reliability in a cloud ecosystem. It’s a must to extract the best benefits of cloud computing.

More often, a lift-and-shift doesn’t make sense because the application can’t take advantage of elastic compute or cloud-native offerings. As a result, institutions frequently face the daunting task of a full refactorization of their critical business applications into microservices. While doing so may be beneficial once realized, it can be risky and is almost always expensive.

At Ness, we’re proud of our perfect track record of rebuilding, re-platforming and refactoring applications for the cloud. There’s no secret sauce to our success in cloud refactoring initiatives, refactoring cloud migration or application refactoring for cloud. Instead, we base our practice on the following pillars:

Focused Approach

When moving legacy applications, a common practice is to replicate the existing system’s functionality exactly. Doing so may be unnecessary—applications that are 10+ years old aren’t built frequently to serve the current needs of a business. Instead of forcing a square peg in a round hole, we might be better off focusing on what the application should be doing rather than on what it’s currently doing.

Domain Knowledge

Technology excellence is required but not enough in cloud refactoring, app refactoring or in the refactorization of functionally rich applications. Our senior staff has decades of financial services domain expertise, and we lean heavily on our business analysts throughout the process, beginning with planning and design.

Refactoring applications into microservices or app refactoring requires that the boundaries of services are appropriately defined. These definitions aren’t engineering constructs but are determined at an organizational and business-function level. Domain-Driven Design (DDD) is an approach that can help define these boundaries, but the domain must be well understood to be effective.

Technical Expertise

Over the years, we’ve built critical trading, risk management, and reporting systems for many of the largest banks, hedge funds, and industry utilities. We’re also a handful of AWS Consulting Partners with the AWS Financial Services Competency. We have more AWS Certifications than we have staff in the company (and we are counting the staff inclusive of Operations and Sales). This level of certification guarantees that everyone on a project, even our business analysts, has rigorous technical training.

Traditionally, legacy systems rely on a “shared state” (e.g., using the same database) as an integration point. One of the patterns facilitating an application’s breakup into microservices is a move toward “shared flow” (e.g., using a redo log like Kafka). This approach allows us to develop components in parallel more easily, scale them, and move some into the cloud while leaving others in a data center as needed.

Iterative Process

Whenever we start on a big re-architecture or a refactorization project, our first milestone is to provide a quick working Proof of Value—will the suggested technology and architecture meet the business and technical requirements? The only way to be sure is to get real data.

We follow a disciplined, iterative process with regular progress demos at the end of each sprint. Even if an application can’t go into production at the end of each sprint, the regular demos of functionality and integration points allow for incremental testing. It removes nasty surprises around go-live, provides early feedback, and enables robust test automation.

Cost Efficiency

We work very closely with AWS and can leverage several AWS funding programs. Our AWS partnership has allowed us to cut our clients’ migration costs by up to half.

Author

Vassil Avramov, Chief Technology Officer, Ness Digital Engineering

FAQs

1. What is Application Refactoring?

It is the process of optimizing software application for performance, scalability and functionality.

2. What are the benefits of refactoring an application?

The benefits include increased scalability, improved reliability, better code quality and functionalities.

3. What is refactoring cloud?

Refactoring cloud is a way to optimize the current application to leverage the benefits of cloud computing.

4. What is the difference between refactoring and migration?

Refactoring is to optimize code structure, design and architecture. Migration is to moving a software from one technology stack to other.

5. What is an example of refactoring?

A good example of refactoring is removing duplicate code from application or to simplify complex algorithms to make it more efficient.