Global
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
