Managing risk during application modernization | Whitepapers Online
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.
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.”