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

What is the Saga pattern?

If you ever did application development on a monolithic or an N-Tier system, you are probably familiar with the concept of a transaction. This is where the application wants to do a Create, Read, Update, or Delete (CRUD) type transaction on a database or multiple databases. It needs to do this consistently across all participating databases. A transaction manager was typically used. It ensured that the transaction as a whole either happened or didn’t happen. The term to refer to this is an ACID transaction. Let’s look at what the ACID acronym stands for:

  • Atomicity: Either the entire transaction happens or does not. There is no in-between state.
  • Consistency: The data being affected by the transaction is in a consistent state both when the transaction starts and when it ends.
  • Isolation: When a transaction is in progress, the state of the transaction is invisible to other transactions that might be running.
  • Durability: After...