Three truths and a lie: Key things to know when moving your legacy environment to the cloud

Few can argue with the significant business and technical benefits associated with shifting workloads from traditional data centers to cloud based infrastructures. But when we think about the workloads running in “traditional data centers,” we really mean legacy-based monolithic applications. And those applications, while often powering mission critical aspects of your business, also happen to be brittle, old, complex and tightly integrated. These aren’t exactly the core traits of “born in the cloud” applications.

While the benefits of the end state destination might be obvious, the act of moving your applications to a cloud environment can be a tricky process. Any approach should therefore be met with a fairly rigorous and progressive approach.

Truth #1: Not all workloads need to be migrated to cloud-native microservices
Cloud-native might be a logical design goal of newly developed cloud workloads. However, there are good reasons not to distill your complete legacy functionality down to an independent set of loosely coupled microservices. The good news is that you probably won’t need to. Certain functionality might be better off staying as a monolith, due to the complexities involved in architecting, managing, scaling and monitoring highly transactional atomic-based workloads, but also because of their steady state (e.g. updated less frequently). Workloads with these characteristics don’t need a continuous delivery model supported by their own team. Disposition strategies for monolithic workloads will depend on business requirements, and may include re-hosting “as-is” with little-to-no change, or refactoring to Java or C# and further optimizing to leverage specific cloud capabilities such as increased elasticity and availability.

It’s critical not to hurry down one modernization path right out of the gate. The best outcome will be achieved by taking a tailored approach, and by developing a strategic modernization roadmap with specific goals for different applications based on individual requirements. Identify a few high value capabilities that you want to decouple, and then progress towards a cloud-native microservices architecture.

Truth #2: You can significantly reduce risk by completing a thorough assessment that combines a top down and bottom up analysis
Lines of business and other stakeholders should not be kept in silos. As such, members of the business teams need to be brought into any modernization conversations from the beginning. This is required in order to proactively address cultural change issues associated with reorganizing teams to support any new development and deployment model, as well as ensure they see the value in this future application state.

A top down and bottom up analysis should be executed in tandem. A top down analysis, driven via workshops using proven approaches and techniques such event storming and domain driven design (DDD) allow the future to be shaped by describing the business and how events flow through the system. Legacy functionality usage has most likely evolved over the years, so incorporating user experience in order to build specific service use cases is also critical.

The purpose of a bottom up analysis is to provide a comprehensive picture of the contents and interrelationships between application components. The cost and complexity of any future modernization effort can be dramatically reduced by isolating unused components, anticipating potential roadblocks and proactively focusing on areas in need of particular concentration. Using our own analysis tools here at Modern Systems, we’ve seen scope reduction results of approximately 40 to 70 percent. A bottom up analysis also helps you expose the legacy application design and understand the anatomy of the source code which is critical for ensuring that the future state architecture doesn’t inherit the very design weaknesses that potentially cause you the greatest amount of pain.

To be able to successfully plan for the different disposition strategies requires a form of structured code analysis to find the tightly coupled dependencies in your code. As such, it’s important to use specialized modernization tooling that can address the outcomes of the top down analysis coupled with a bottom up analysis.

Truth #3: Moving to the cloud is best approached as an incremental journey
A byproduct of any good assessment should be a strategic modernization roadmap containing a multi-phased approach to achieving a ROI at each step of the migration. There are different levels of maturity to consider when moving through this incremental journey: Cloud ready, cloud optimized and cloud native.

While cloud native is the ideal destination for “born in the cloud” greenfield development projects, a logical first phase option for monolithic applications is to automatically convert code into cloud native languages such as Java or C#. In this situation, by removing the dependency on the mainframe, you can target a cloud ready containerized environment optimized to take advantage of many of the benefits that the cloud has to offer. In a cloud optimized environment, workloads are optimized further to provide scalability at the container level, while replacing a few high-value capabilities with new microservices functionality. Further optimization efforts can continue at your own pace in order to incrementally move towards a cloud native environment, realizing that you might never replace the entire monolith.

Lie #1: You don’t need to worry about operations and infrastructure
In a typical modernization project, around 40 percent of the effort is focused on application source code and data conversion, with 40 to 50 percent expended on testing, and the remaining 10 to 20 percent spent on designing, implementing and managing the target operations and hardware infrastructure. The target platform should never be an afterthought. This is especially true when deploying to a cloud environment. The reality is that a legacy environment comes with well-established operational and infrastructure standards and processes. A major challenge you’ll face as you embrace a cloud-native microservices approach is the required level of operational readiness and skilled resources needed to support the new, continuous delivery processes. Building out the target environment as part of the incremental journey will give your team tasked with managing it time to adjust before any microservices-driven projects even begin.

Being able to get to the cloud in general is a good thing, to help you gain quick access to new services, platforms and toolsets.

Once you have a cloud native infrastructure in place, you will be operating your business with a modern application foundation which will support vastly improved innovation, continuous improvement, faster development cycles, agility and flexibility. Hopefully you will also be on a faster track to focusing on what matters most to your core business: exceeding your customer expectations with rapid introduction of relevant products and services.

Share This

Share This

The world needs to know more about modernization. Help us spread the word!