The Business Case for Application Modernization

While the official guidance by AWS recommends that applications should be re-architected as part of a cloud migration, a compromise between the business and its technical leadership often results. This compromise curbs the more aspirational goals of the cloud adoption framework often defaulting exclusively to a “lift and shift” migration strategy.

The business drivers for this compromise are financial and strategic:

• The immediate cost savings realized by eliminating data centers.
• The immediate cost savings realized by reducing redundant IT staff.
• Conversion of IT costs from capex to opex.
• Refocusing IT staff to deliver solutions that directly support their core business strategy.
• After the last datacenter is shut down and the business is enjoying the immediate value capture from a more accelerated migration path,
• application modernization is the next logical investment.

Application modernization in the context of cloud generally means the re-architecting of existing applications to fully leverage cloud native services, especially managed cloud services.

Modern architectures can deliver:

• Scalability to meet future growth in demand.
• Dynamic elasticity to cost effectively handle peak or unpredictable loads.
• Cost and maintenance efficiency by leveraging on demand, serverless compute.
• Robustness and operational resiliency by decoupling services and by leveraging managed services.
• Increased speed of future solution delivery.

Each application potentially brings unique considerations and challenges, but some common architectural guidance is presented here to aid technologists in understanding how application modernization is implemented.

Databases

Multi-use databases that were lifted and shifted may be running standalone on EC2 instances. This self-managed configuration still requires dba support for backups, disk space and health monitoring. Licensing issues may be a motivating factor as companies seek to fully consume existing licenses. Migrating self-managed databases to fully managed database services provides better durability and reliability as well as eliminating database infrastructure support needs.

N-tiered Architectures

Many legacy applications implement a tiered architecture often consisting of a data persistence layer, a business logic layer, and an interface.

There are limited migration paths for the data persistence layer. If the database is self-managed running on an EC2 instance or even if it was originally migrated to an RDS instance, a clustered relational database that can scale horizontally like Aurora Serverless may be appropriate.

At the business logic layer, heavy components written in Java or C# that are stateful and tightly coupled to the other application tiers are likely to appear. This architecture does not scale. A modern architecture might implement this as a microservices architecture or a stateless application hosted in an autoscaling group behind a load balancer. Serverless and event-driven architectures utilizing Lambdas, SQS, and application triggers may also be used.

Microservices Architectures

The Service Oriented Architectures (SOA) that rose to prominence in the 2000s has been replaced by microservices architecture theory. Bulky monolithic services are decomposed into separate, more granular services where each service does a lot less. This paradigm shift is motivated by the single responsibility principle, which states that “every module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated.” While a microservice may group functionality together where appropriate this provides insight into the guiding tendency to decouple previously coupled services.

A consequence of microservice architecture is that requests are processed asynchronously, making applications more responsive, and allowing any service disruptions to recover gracefully.

Batch vs Streaming Architectures

Another common pattern for application modernization is the conversion of batch to streaming data architectures. This is often driven by business cases requiring a shorter time to answer than what is currently possible with a batch architecture. Streaming architectures decouple publishing from consuming, adding asynchronous access and flexibility to any downstream data processing.

Containerization & DevOps

Containerization is an imperative in the application modernization context. What containerization allows is the full separation of concerns: infrastructure, application services, and data.

Defining infrastructure as code ensures that the infrastructure the application runs on can be reproduced with 100% fidelity while managing any modifications through traditional software configuration management practices. Containerizing the application code allows it to be deployed to various infrastructures, including on premises as part of a hybrid cloud.

Implementing CI/CD pipelines for the application code ensures that the application is fully decoupled from its infrastructure, unit testing and regression testing can be automated, and if desired, releases also can be scheduled and deployments automated.

The cloud ecosystem and the use of these different strategies, services, and tools means that better monitoring, logging, and alerting is easily achievable. Better capabilities in this area means fewer IT resources are needed to manage an expanding portfolio of applications, freeing resources to solve the next business problems.

The underpinning of any technology strategy is the business case. Not every application will be a candidate for modernization as the costs to modernize can exceed the value added to the business. Luckily there are a few resources and frameworks to guide this analysis.

In 2000, Gartner published research often referred to as “the 5 Rs” (Rehost, Refactor, Revise, Rebuild, or Replace) to assist in the classification and prioritization of applications as part of a cloud migration effort. Although the paper is 10 years old, many of the concepts still apply. Another approach is formally referred to as the Applications Portfolio Analysis (APA) and it consists of classifying applications into three buckets: utility, enhancement, and frontier.

Paraphrasing this guidance, priority should be given to applications that drive the core business. This could include a product or service that generates revenue or directly supports revenue generation. The usefulness of certain legacy applications may allow for them to be decommissioned after a sunsetting period. The functionality of other legacy applications can be replaced by new offerings rather than be migrated.

The last part of an application modernization strategy is execution. The business can seek to source the talent and resources internally, hire directly from the current labor market, or leverage a 3rd party integrator. Application modernization in the cloud context is a complex challenge, especially when aggressive timelines and strict budgets are constraints. The technology staff at most enterprises despite being one or two years into their cloud adoption journey will likely not be properly experienced to execute an ambitious application modernization effort. The daily grind of existing operational maintenance issues and development initiatives may make it difficult or risky to reassign them. Most business savvy technology leaders will recognize quickly that leveraging a 3rd party integrator is the right strategy.

Picking the right 3rd party integrator is vital to mitigating the risk of project failure. NorthBay is an experienced solutions delivery company where solution delivery and application modernization is its core business.