Managing Risk In Application Modernization

Enterprises looking to leverage platform-as-a-service (PaaS) such as Pivotal Cloud Foundry and Red Hat Open Shift, typically start with two application environments:  

• New initiatives (greenfield) that can be built from the ground up using cloud native best practices 
•  Existing application environments (brownfield) that they would like to modernize for the agility, scalability and performance benefits of cloud

Many of the existing workloads (brownfield) are critical applications to the business, generate substantial revenue, and are sensitive to disruption. While it would be ideal to completely re-architect these applications using cloud native principles, it is generally not practical or cost effective to do so. 

This briefing provides practical advice and best practices on where and how to get started with the refactoring of a monolithic application. In combination, this helps IT teams accelerate the modernization process and reduces the risk of impacting customer events and business processes along the way.

See also: What you need to know before replacing your current AV solution 

Where to start?

Identifying candidates and components for refactoring. Before we begin, let’s set the stage with a couple of assumptions:

You are starting with a well-structured monolith:

Before you start the process of refactoring elements of your monolith, you will need to do some work to ensure that it is well-structured. If you are not sure if you are starting with a well-structured Monolith, learn more by taking a look at this video “Modular Monoliths” by Simon Brown (@simonbrown), an industry consultant in software architecture.

You are using DevOps practices and tools:

To get the most out of cloud-native you need to be following DevOps best practices and using automation tooling for continuous integration (CI)/continuous delivery (CD). For more information on this, take a look at the eBook “Lessons Learned While Writing The DevOps Handbook” by authors: Gene Kim, Mark Tomlinson, Andi Grabner.

What is a monolith and how do I refactor it?

We tend to think of monoliths as being something bad in today’s new world of distributed, loosely coupled application architectures. If you have a well-structured monolith, the only bad parts about it are that it is a single codebase and to scale it you must scale the entire thing. At its very essence, “From a software perspective, a monolith is a combination of business capabilities or bounded contexts all enmeshed with a core context. The process of transforming an app to a microservices based architecture entails separation of each of these bounded contexts into their own contexts.” 

Download Dynatrace's whitepaper to learn more about how to manage risks during application modernization efforts.