Op werkdagen voor 23:00 besteld, morgen in huis Gratis verzending vanaf €20

Architecting for Scale

How to Maintain High Availability and Manage Risk in the Cloud

Paperback Engels 2020 9781492057178
Laatste exemplaar! Op=Op!
Op voorraad | Op werkdagen voor 21:00 uur besteld, volgende dag in huis


Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. With the popularity of software as a service, scaling has never been more important.

Updated with an expanded focus on modern architecture paradigms such as microservices and cloud computing, this practical guide provides techniques for building systems that can handle huge quantities of traffic, data, and demand—without affecting the quality your customers expect. Architects, managers, and directors in engineering and operations organizations will learn how to build applications at scale that run more smoothly and reliably to meet the needs of customers.

- Learn how scaling affects the availability of your services, why that matters, and how to improve it
- Dive into a modern service-based application architecture that ensures high availability and reduces the effects of service failures
- Explore the Single Team Owned Service Architecture paradigm (STOSA)—a model for scaling your development organization in tandem with your application
- Understand, measure, and mitigate risk in your systems
- Use the cloud to build highly scalable applications


Aantal pagina's:230
Hoofdrubriek:IT-management / ICT


Wees de eerste die een lezersrecensie schrijft!

Geef uw waardering

Zeer goed Goed Voldoende Matig Slecht

Over Lee Atchison

Lee Atchison is the Senior Director, Cloud Architecture at New Relic. For the last seven years he has helped design and build a solid service-based product architecture that scaled from startup to high traffic public enterprise. Lee has 32 years of industry experience including seven years as a Senior Manager at Amazon.com. At Amazon, he led the creation of the company’s first software download store, created AWS Elastic Beanstalk, and managed the migration of Amazon’s retail platform to a new service-based architecture. Lee has consulted with leading organizations on how to modernize their application architectures and transform their organizations at scale; including optimize for cloud platforms, utilize service based architectures, implement DevOps practices, and design for high availability. This experience lead him to write his book “Architecting for Scale”, published in 2016 by O’Reilly Media. Lee is an industry expert and is widely quoted in publications such as Diginomica, IT Brief, Programmable Web, CIO Review, and DZone. He has been a featured speaker at events across the globe from London to Sydney, Tokyo to Paris, and all over North America.

Andere boeken door Lee Atchison


Foreword for Second Edition
Foreword for First Edition
Who Should Read This Book
Why I Wrote This Book
A Word on Scale Today
What’s New in the Second Edition
Using the Cloud
Services Versus Microservices
Modern Digital Customer Experiences
Navigating This Book
Tenet 1. Availability: Maintaining Availability in Modern Applications
Tenet 2. Modern Application Architecture: Using Services
Tenet 3. Organization: Scaling Your Organization for Modern Applications
Tenet 4. Risk: Risk Management for Modern Applications
Tenet 5. Cloud: Utilizing the Cloud
Online Resources
Conventions Used in This Book
O’Reilly Online Learning
How to Contact Us

Part I: Tenet 1. Availability: Maintaining Availability in Modern Applications
1. Understanding, Measuring, and Improving Your Availability
Availability Versus Reliability
What Causes Poor Availability?
Measuring Availability
The Nines
Planned Outages Are Still Outages
Availability by the Numbers
Improving Your Availability When It Slips
Measure and Track Your Current Availability
Automate Your Manual Processes
Improve Your Systems
Keep on Top of Availability in Your Changing and Growing Application
Five Focuses to Improve Application Availability
Focus #1: Build with Failure in Mind
Focus #2: Always Think About Scaling
Focus #3: Mitigate Risk
Focus #4: Monitor Availability
Focus #5: Respond to Availability Issues in a Predictable and Defined Way
Being Prepared

2. Two Mistakes High—Having Room to Recover from Mistakes
Two Mistakes High
Scenario #1: Losing a Node
Scenario #2: Problems During Upgrades
Scenario #3: Data Center Resiliency
Scenario #4: Hidden Shared Failure Types
Scenario #5: Failure Loops
Managing Your Applications
The Space Shuttle

Part II: Tenet 2. Modern Application Architecture: Using Services
3. Using Services
The Monolith Application Versus the Service-Based Application
The Ownership Benefit
The Scaling Benefit
Splitting into Services
What Should Be a Service?
Dividing into Services
Guideline #1: Specific Business Requirements
Guideline #2: Distinct and Separable Team Ownership
Guideline #3: Naturally Separable Data
Guideline #4: Shared Capabilities/Data
Mixed Reasons
Going Too Far
Finding the Right Balance

4. Services and Data
Stateless Services—Services Without Data
Stateful Services—Services with Data
Data Partitioning
Timely Handling of Growing Pains

5. Dealing with Service Failures
Cascading Service Failures
Responding to a Service Failure
Predictable Response
Understandable Response
Reasonable Response
Determining Failures
Appropriate Action
Graceful Degradation
Graceful Backoff
Fail as Early as Possible
Customer-Caused Problems

Part III: Tenet 3. Organization: Scaling Your Organization for Modern Applications
6. Service Ownership—STOSA
Single Team Owned Service Architecture
Advantages of a STOSA Application and Organization
What Does It Mean to “Own” a Service?
Using Core Teams and Services

7. Service Tiers
Application Complexity
What Are Service Tiers?
Assigning Service Tier Labels to Services
Example: Online Store
Using Service Tiers

8. Service-Level Agreements
What Are SLAs?
External Versus Internal SLAs
Why Are Internal SLAs Important?
SLAs for Problem Diagnosis
Performance Measurements for SLAs
Limit SLAs
Top Percentile SLAs
SLA Conditionals
How Many and Which Internal SLAs?
Why Internal SLAs Are Important

Part IV: Tenet 4. Risk: Risk Management for Modern Applications
9. Using Risk Management When Architecting for Scale
Identify Risk
Remove Worst Offenders
Review Regularly
Managing Risk Summary
Likelihood Versus Severity
The Top 10 List: Low Likelihood, Low Severity Risk
The Order Database: Low Likelihood, High Severity Risk
Custom Fonts: High Likelihood, Low Severity Risk
T-Shirt Photos: High Likelihood, High Severity Risk
The Risk Matrix
Scope of the Risk Matrix
Creating the Risk Matrix
Using the Risk Matrix for Planning
Maintaining the Risk Matrix
Risk Mitigation
Recovery Plans
Disaster Recovery Plans
Improving Our Risk Situation

10. Game Days
Staging Versus Production Environments
Staging/Test Environments
Production Environments
Concerns with Running Game Days in Production

11. Building Systems with Reduced Risk
Technique #1: Introduce Redundancy
Idempotent Interfaces
Redundancy Improvements That Increase Complexity
Technique #2: Understand Independence
Technique #3: Manage Security
Technique #4: Encourage Simplicity
Technique #5: Build in Self-Repair
Technique #6: Standardize on Operational Processes

Part V: Tenet 5. Cloud: Utilizing the Cloud
12. Getting Started Architecting for Scale with the Cloud
Six Levels of Cloud Maturity
Level 1: Experimenting with the Cloud
Level 2: Securing the Cloud
Level 3: Using Servers and Applications in the Cloud
Level 4: Enabling Value-Added Managed Services
Level 5: Enabling Cloud-Unique Services
Level 6: Cloud All In
Organization Versus Application Maturity Level
Cloud Adoption Mistakes
Trap #1: Not Trusting Cloud Security
Trap #2: Performing Cloud Migration via Lift-and-Shift
Trap #3: The Lure of Serverless—Depending Too Much on the Hype
When and How to Use Multiple Clouds
Defining What We Mean by Multiple Clouds
Which Model? Which Cloud?
The Cloud in Summary

13. Five Industry Trends Changed by the Cloud
What Has Changed in the Cloud?
Change #1: Acceptance of Microservice-Based Architectures
Change #2: Smaller, More Specialized Cloud Services
Change #3: Greater Focus on the Application
Change #4: The Micro Startup
Change #5: Security and Compliance Has Matured
Change Continues

14. Types of SaaS and Tenancy
Comparing Managed Hosting and Different Types of SaaS
Managed Hosting
Multi-Tenant SaaS
Single-Tenant SaaS
Mixing Different Types of SaaS
Common SaaS Characteristics
SaaS Versus Managed Hosting

15. Distributing Your Application in the AWS Cloud
AWS Architecture
AWS Region
AWS Availability Zone
Data Center
Architecture Overview
Availability Zones Are Not Data Centers
Maintaining Location Diversity for Availability Reasons
AWS—Mapping Availability Zones in Multiple Accounts
Distributing Your Application

16. Managed Infrastructure
Structure of Cloud-Based Services
Raw Resource
Server-Based Managed Resource
Serverless Managed Resource
Implications of Using Managed Versus Non-Managed Resources

17. Cloud Resource Allocation
Usage-Based Resources Allocation
Allocated-Capacity Resource Allocation
Changing Allocations
Automated Allocation of Resource Capacity
Issues with Automatic Allocation
Dynamic Allocation, Dynamic Cost
Pros and Cons of Usage-Based Versus Allocated-Capacity

18. Serverless and Functions as a Service
Example Application #1: Event Processing
Example Application #2: Mobile Backend
Example Application #3: Internet of Things Data Intake
Advantages and Disadvantages of FaaS
Serverless Hype and the Future of FaaS

19. Edge Computing
Edge Computing Today
Why We Care
What Should Be in the Edge Versus the Cloud?
How Do We Decide? The Driverless Car
Edge Scaling Isn’t the Same as Cloud Scaling
Criteria for Using Edge Versus Cloud
Eight Keys to Success in the Edge
#1: Be Smart About What Goes on the Edge
#2: Don’t Ignore DevOps Principles in the Edge
#3: Nail a Highly Distributed Deployment Strategy
#4: Reduce Versioning as Much as Possible
#5: Reduce Per Node Provisioning and Configuration Options
#6: Scaling Is an Edge Issue, Not Just a Cloud Issue
#7: Nail Monitoring and Analytics
#8: The Edge Is Not Magic
Edge Computing Overall

20. Geographic Impact on Using the Cloud
Cloud Matters Everywhere, But at Different Levels
Replacement Mentality Impacts How You Adopt Cloud
Which Cloud Is Most Important?
Important Technologies Differ
Data Sovereignty Is Universal
My Take

Part VI: Conclusion
21. Putting It All Together
Tenet #1—Availability
Tenet #2—Architecture
Tenet #3—Organization
Tenet #4—Risk
Tenet #5—Cloud
Architecting for Scale


Managementboek Top 100


Populaire producten



        Architecting for Scale