Book Club: The DevOps Handbook (Chapter 13. Architect for Low-Risk Releases)

The following is a chapter summary for “The DevOps Handbook” by Gene Kim, Jez Humble, John Willis, and Patrick DeBois for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on The DevOps Handbook

More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater―whether it’s the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.

And yet, high performers using DevOps principles, such as Google, Amazon, Facebook, Etsy, and Netflix, are routinely and reliably deploying code into production hundreds, or even thousands, of times per day.

Following in the footsteps of The Phoenix Project, The DevOps Handbook shows leaders how to replicate these incredible outcomes, by showing how to integrate Product Management, Development, QA, IT Operations, and Information Security to elevate your company and win in the marketplace.

The DevOps Handbook

Chapter 13

Strangler Application Pattern — instead of “ripping out and replacing” old services with architectures that no longer support our organizational goals, the existing functionality is put behind an API and further changes to the old service are avoided. All new functionality is then implemented in the new services that use the new desired architecture, making calls to the old system when necessary.

Charles Betz, author of Architecture and Patterns for IT Service Management, Resource Planning, and Governance, observes, “[IT project owners] are not held accountable for their contributions to overall system entropy.”

Reducing overall complexity and increasing the productivity of all development teams is rarely the goal of an individual project.

An Architecture That Enables Productivity, Testability, and Safety

Loosely-coupled architecture with well-defined interfaces enforce how modules connect with each other promotes productivity and safety. It enables small, productive, two-pizza teams that are able to make small changes that can be safely and independently deployed. Since each service also has a well-defined API, it enables easier testing of services and the creation of contracts and SLAs between teams.

Architecture Patterns Pros and Cons

Monolithic (all functionality in one application):

• Pro: Simple at first
• Pro: Low inter-process latencies
• Pro: Single codebase, one deployment unit
• Pro: Resource-efficient at small scales
• Con: Coordination overhead increases as team grows
• Con: Poor enforcement of modularity
• Con: Poor scaling
• Con: All-or-nothing deploy (downtime, failures)
• Con: Long build times

Monolithic (set of monolithic tiers: “front end”, “application server”, “database layer”):

• Pro: Simple at first
• Pro: Join queries are easy
• Pro: Single schema, deployment
• Pro: Resource-efficient at small scales
• Con: Tendency for increased coupling over time
• Con: Poor scaling and redundancy (all or nothing, vertical only)
• Con: Difficult to tune properly
• Con: All-or-nothing schema management

Microservice (modular, independent, graph relationship vs tiers, isolated persistence):

• Pro: Each unit is simple
• Pro: Independent scaling and performance
• Pro: Independent testing and deployment
• Pro: Can optimally tune performance (caching, replication, etc.)
• Con: Many cooperating units
• Con: Many small repos
• Con: Requires more sophisticated tooling and dependency management
• Con: Network latencies

Use the Strangler Application Pattern to Safely Evolve Enterprise Architecture

The term strangler application was coined by Martin Fowler in 2004 after he was inspired by seeing massive strangler vines during a trip to Australia, writing, “They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.”

The strangler application pattern involves placing existing functionality behind an API, where it remains unchanged, and implementing new functionality using the desired architecture, making calls to the old system when necessary. When teams implement strangler applications, they seek to access all services through versioned APIs, also called versioned services or immutable services.

Series Navigation