Book Image

Modernizing Legacy Applications to Microsoft Azure

By : Steve Read, Larry Mead
Book Image

Modernizing Legacy Applications to Microsoft Azure

By: Steve Read, Larry Mead

Overview of this book

Organizations have varying circumstances, objectives, and prerequisites when contemplating a hyper-scale cloud solution transformation to a platform such as Azure. Modernizing Legacy Applications to Microsoft Azure uncovers potential scenarios and provides choices, methodologies, techniques, and prospective possibilities for transitioning from legacy applications to the Microsoft Azure environment. You’ll start by understanding the legacy systems and the main concerns regarding migration. Then, you’ll investigate why distributed architectures are compelling and the various components of the Azure platform needed during migration. After that, you’ll explore the approaches to modernizing legacy applications and the Rs of modernizing (i.e., rehost, refactor, rearchitect, and retire). You’ll also learn about integration approaches and potential pitfalls. By the end of this book, you’ll be well equipped to modernize your legacy workloads while being aware of pitfalls and best practices.
Table of Contents (18 chapters)
1
Part 1: Legacy Estate Options
3
Chapter 2: Strategies for Modernizing IBM and Unisys Mainframes
6
Part 2: Architecture Options
10
Part 3: Azure Deployment and Future Considerations

Understanding how we got here – the evolution of application development

Before we dive into the best practices for modernizing monolithic applications, let’s take a step back and look at how we got here. As you may recall from Chapter 7, monolithic application design has a direct relationship with the hardware at the time. The hardware environment was typically a large mainframe computer with communication devices hooked up to it for users and input/output (I/O) devices. Applications and their related components were tightly integrated into a single code base. This meant that over time, as certain features and functionality needed to be updated, the entire monolith needed to be recompiled.

Gradually, as applications grew larger and more complex, developers began to break these monoliths into smaller, more manageable components called modules. I remember back in the 1980s when modular application development was all the rage. There was even a language called Modula...