Book Image

Cloud Native Architectures

By : Tom Laszewski, Kamal Arora, Erik Farr, Piyum Zonooz
Book Image

Cloud Native Architectures

By: Tom Laszewski, Kamal Arora, Erik Farr, 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. To harness this, businesses need to refresh their development models and architectures when they find they don’t port to the cloud. Cloud Native Architectures demonstrates three essential components of deploying modern cloud native architectures: organizational transformation, deployment modernization, and cloud native architecture patterns. This book starts with a quick introduction to cloud native architectures that are used as a base to define and explain what cloud native architecture is and is not. You will learn what a cloud adoption framework looks like and develop cloud native architectures using microservices and serverless computing as design principles. You’ll then explore the major pillars of cloud native design including scalability, cost optimization, security, and ways to achieve operational excellence. In the concluding chapters, you will also learn about various public cloud architectures ranging from AWS and Azure to the Google Cloud Platform. By the end of this book, you will have learned the techniques to adopt cloud native architectures that meet your business requirements. You will also understand the future trends and expectations of cloud providers.
Table of Contents (19 chapters)
Title Page
Packt Upsell
Foreword
Contributors
Preface
Index

Two-pizza teams


The fundamental issue with large organizations is consensus-building. Consensus is needed to move forward on most projects due to the interdependent nature of how we build our technology systems. Since systems are typically large and span multiple teams, once one team makes changes to their part of the system, it may have upstream and downstream effects that they did not anticipate (on subsystems owned and maintained by other teams). The following are some examples:

  • Upstream effect: The updated subsystem now operates so quickly that it is straining the data feed with pulls for new data
  • Downstream effect: The updated subsystem is generating data much more quickly which is overwhelming the ability of the downstream consumer to process the feed

With the broad adoption of decoupled systems and SOAs, we solve this from a technology aspect, but the organization has yet to adapt to this new reality. If we have decoupled systems, why not decoupled organizational units? Enter the two...