Book Image

Cloud Native Development Patterns and Best Practices

By : John Gilbert
Book Image

Cloud Native Development Patterns and Best Practices

By: John Gilbert

Overview of this book

Build systems that leverage the benefits of the cloud and applications faster than ever before with cloud-native development. This book focuses on architectural patterns for building highly scalable cloud-native systems. You will learn how the combination of cloud, reactive principles, devops, and automation enable teams to continuously deliver innovation with confidence. Begin by learning the core concepts that make these systems unique. You will explore foundational patterns that turn your database inside out to achieve massive scalability with cloud-native databases. You will also learn how to continuously deliver production code with confidence by shifting deployment and testing all the way to the left and implementing continuous observability in production. There's more—you will also learn how to strangle your monolith and design an evolving cloud-native system. By the end of the book, you will have the ability to create modern cloud-native systems.
Table of Contents (12 chapters)

Strangler pattern

The Strangler pattern was first coined by Martin Fowler in 2004 (https://www.martinfowler.com/bliki/StranglerApplication.html) after the amazing Australian Strangler Vines. These vines envelop their host fig tree and eventually kill off the host and support themselves. This is an excellent analogy for how we want to incrementally migrate and re-architect a legacy system into a cloud-native system. This is not a big-bang, high-risk process. It is a methodical process that leaves the legacy system in place for as long as necessary, while valuable enhancements are made around the legacy system using the new architecture.

A critical aspect of this approach is the notion of valuable enhancements. Traditional migrations can stretch on and on with skyrocketing costs and with little to no perceived business value being created. These projects rarely end well. Instead...