Book Image

Architecting Cloud Native Applications

By : Kamal Arora, Erik Farr, John Gilbert, Piyum Zonooz
Book Image

Architecting Cloud Native Applications

By: Kamal Arora, Erik Farr, John Gilbert, Piyum Zonooz

Overview of this book

Cloud computing has proven to be the most revolutionary IT development since virtualization. Cloud native architectures give you the benefit of more flexibility over legacy systems. This Learning Path teaches you everything you need to know for designing industry-grade cloud applications and efficiently migrating your business to the cloud. It begins by exploring the basic patterns that turn your database inside out to achieve massive scalability. You’ll learn how to develop cloud native architectures using microservices and serverless computing as your design principles. Then, you’ll explore ways to continuously deliver production code by implementing continuous observability in production. In the concluding chapters, you’ll learn about various public cloud architectures ranging from AWS and Azure to the Google Cloud Platform, and understand the future trends and expectations of cloud providers. By the end of this Learning Path, you’ll have learned the techniques to adopt cloud native architectures that meet your business requirements. This Learning Path includes content from the following Packt products: • Cloud Native Development Patterns and Best Practices by John Gilbert • Cloud Native Architectures by Erik Farr et al.
Table of Contents (24 chapters)
Title Page
Copyright and Credits
About Packt
Contributors
Preface
Index

Bounded isolated components


We have defined the architectural vision for our cloud-native systems and enumerated the patterns used to build these systems. The next step is to decompose a system into bounded isolated components. However, “What is the right size?” is a fundamental question that everyone asks. Ultimately, every team has to answer this question for itself. You have to ask yourself how confident you are that you can continuously deploy and scale each component. If you cannot be certain of the implications of a given change to a component then the component is potentially too large. If you have to make compromises on the scalability and tuning of a specific component then it likely needs to be split apart. If the backlog of changes to a component starts to clog then this is an indication that it may need to be refactored into multiple components. The potential scenarios may be limitless. In this section, we discuss common strategies for decomposing cloud-native systems into bounded...