Book Image

Architecting Cloud Computing Solutions

By : Kevin L. Jackson, Scott Goessling
Book Image

Architecting Cloud Computing Solutions

By: Kevin L. Jackson, Scott Goessling

Overview of this book

Cloud adoption is a core component of digital transformation. Scaling the IT environment, making it resilient, and reducing costs are what organizations want. Architecting Cloud Computing Solutions presents and explains critical cloud solution design considerations and technology decisions required to be made for deploying the right cloud service and deployment models, based on your business and technology service requirements. This book starts with the fundamentals of cloud computing and its architectural concepts. It then walks you through cloud service models (IaaS, PaaS, and SaaS), deployment models (public, private, community, and hybrid) and implementation options (enterprise, MSP, and CSP) to explain and describe the key considerations and challenges organizations face during cloud migration. Later, this book delves into how to leverage DevOps, Cloud-Native, and serverless architectures in your cloud environment and presents industry best practices for scaling your cloud environment. Finally, this book addresses in depth how to manage essential cloud technology service components, such as data storage, security controls, and disaster recovery. By the end of this book, you will have mastered all the design considerations and operational trades required to adopt cloud services, no matter which cloud service provider you choose.
Table of Contents (24 chapters)
Free Chapter
1
Prologue
18
Hands-On Lab 1 – Basic Cloud Design (Single Server)
20
Hands-On Lab 3 – Optimizing Current State (12 Months Later)
21
Cloud Architecture – Lessons Learned
22
Epilogue

Economics, not pricing – Economics

It is important to switch the thinking from what the cost is for assembled technical answers and move to using economic data as an integral part of the solution design process. Today, we go through the design process four or five times, first for assembling a reasonably correct technical answer then pulling it apart in layers, trying to back down to something that is within economic reach yet in a technically desired direction.

If we switch that model and move to looking at designing with economics from the very beginning, we can eliminate nearly all recirculating effort as designs are built then redesigned in the current process. It is also important to keep in mind that much of the technical detail affects implementation details more than it does strategy or economics. If it does not materially affect strategy or dramatically change...