Antifragile Software cover page
Antifragile Software

Antifragile Software

Building Adaptable Software with Microservices


We’ve spent over a decade now becoming more and more agile and adaptable in our ways of working. Unfortunately our software is now struggling to keep up with the pace of innovation that is increasingly being demanded by modern businesses. It's time to sort that out. It's time for Antifragile Software with Microservices.
Antifragile Software Edit
This book is 25% complete

Updated

About the Book

Antifragile Software is now proudly donating 20% of its net proceeds to YoungMinds.org.uk

I'm very proud to announce that 20% of all net income from this book is now being donated to YoungMinds.org.uk.

In addition the minimum price for this book has been lowered in-line with the amount of the book currently written. The intention is to take the proceeds made so far and calculate how much should be donated to YoungMinds.org.uk as the difference between that which as been paid and the new minimum price. As the book is completed the minimum price will rise to the full book price, donating the 20% of the net at each price point to the charity.

----

There's no reason to have an agile process if your software can't keep pace.

This book is a collection of patterns that you can apply to build software that thrives on change and the disorder it brings.

This book is broken into three books that deal with the key challenge of software development today, namely how your software adapts to keep pace with the speed of innovation. The top level table of contents includes:

Book 1 - The Philosophy of Change in Software, includes:

  • Software Architecture is Philosophy
  • Stressors on Software
  • Antifragility in Software
  • Simplicity in Software

Book 2 - Architecture and Design for Antifragility

  • Introducing the Life Preserver
  • Phase 1: Organise, Reduce and Encapsulate
  • Phase 2: Group things together that Change Together
  • Phase 3: Jumpting Fault Lines with the Event Domain
  • Phase 4: Considering Failure
  • Phase 5: Cells and Microservices
  • Going Direct

Book 3 - Implementing and Running Antifragile Software

  • Simple Event-Driven Components and Functions
  • Complexity and the Event Domain
  • Microservices
  • Reactive microservices

This book accompanies the "Antifragile Software with Microservices" course by Simplicity Itself at Skills Matter, currently running publicly in London.

This is currently an Alpha version of the book. It is under active development right now. Upgrades until the book is completed will of course be free!

Read More

Table of Contents

  • Preface
    • Why YoungMinds.org.uk?
    • Grabbing the Code
    • Option 1: Browse the code on GitHub
    • Option 2: Download the Code as Zip Files
    • About The Author
    • About Simplicity Itself
    • Acknowledgements
  • Introduction
    • What this book is NOT about
    • Philosophical Underpinnings
    • Axioms
    • What are we really dealing with, then?
    • A Nod Towards Over-Production
  • Book I - The Philosophy of Change in Software
  • The Parable of The Elephant in the Standup
    • Option 1: It’s a Big Change, no honestly…
    • Option 3: The Extended-Holiday of ‘Refactoring’
  • Software Architecture is Philosophy
    • What is Philosophy?
    • Software Architecture Abides
    • Plato and the Waterfall
    • Agility and Fortuna
    • Architecture needs to embrace Fortuna
  • Stressors on Software
  • Antifragility in Software
    • Change, Adaption and Anti-fragility
    • The Change Stressor and the Adaption Response
    • Defining Antifragile Software Systems
    • The Need for Antifragility in Software: Enabling Innovation
    • Emergence and Antifragility
    • Antifragility is in the Relationships
    • Love is Antifragile, an interlude
    • Relationships between Parts are the Key
  • Simplicity in Software, Defined
    • Simplicity is Objective
    • Simple Learning through Koans
    • Koa-what!?
    • Koan: Counting the Concerns
    • The Simplicity Continuum
    • Essential & Accidental Complexity
    • Why do we introduce accidental complexity in the first place?
    • Simple Architecture & Design?
  • Microservice-based Architectures for Antifragility & Simplicity
    • Embracing Change with Microservices
    • Embracing or even Thriving on Change in the Links between Microservices
    • Peers and Pipelines
  • Remember & Apply
  • Book II - Architecture & Design for Antifragility
  • Introducing the Life Preserver
    • What makes a good diagram?
    • The problems of existing diagrams
    • The Pizza Box & The Snow Man
    • Focus on Speed of Evolution through Life Preservation
    • The Life Preserver Tool and Process
    • Green and Brown Fields Welcome!
  • Phase 1: Organising, Reducing and Encapsulating for Simplicity
    • Reducing the term, ‘Component’
    • Where does my component go?
    • What should my component do?
    • When should I split my component?
    • Consider Technologies NOW
    • Focus on what’s right for the Component
  • Phase 2: Group Things Together That Change Together
    • (Re) organise for change
    • Bounded Contexts, Boundaries & Fracture Lines with Tectonic Plates
    • What ‘could’ change
    • Naive is ok, at first
    • Having a Conversation about Change
  • Phase 3: Jumping the Fault Lines with the Event Domain
    • Seeing Inter-Plate and -Component Communication
    • Friction at the Fault Lines
    • Focus on where the Friction is Greatest
    • Complex Relationships, Simple Components
    • Introducing the Event Domain
    • Thinking about De-Coupling
    • Focus on Contract First
    • How should my Components Communicate? Design Events
    • How should my Events be transmitted? Design Dispatch
    • How should my Events be Encoded? Design Payload
    • Pay for Flexibility with Complexity
    • Dealing with Loose Contracts with Postel’s Law
    • A Word on Transactional Boundaries
    • Testing your Inter-Plate Change Coupling
  • Phase 4: Considering Failure
    • Back to Reality: Stressors
    • Don’t isolate from Stressors, Adapt!
    • What can go wrong, will
    • Assume Nothing
    • Event Sourcing
    • Circuit Breaker
    • Let it Fail
    • A Stressor too Far
  • Phase 5: Cells & Microservices
    • Breaking Apart the Monolithic Life Preserver
    • Component to Cell
    • The Strangler ‘Opportunity’
    • Cell to Microservice
    • One Purpose, One Service
    • Assume Nothing (again)
    • Tech Matters More Than Ever!
    • Enabling Polyglot Emergence
    • Polyglot Services by Default
    • Use the Lunchtime Spike, Luke
    • Minimise Infrastructure Requirements
  • Going Direct
    • Dodging the Monolith
    • Phase 5 Only
    • Remember & Apply
  • Book III - Implementing & Running Antifragile Software
  • Simple Event-Driven Components & Functions
  • (Re)introducing the Single Responsibility Principle
    • Tangling and Scattering
    • Reduction to “Doing one thing well”
    • Reduction to Functions
    • Treating your API as a public API
    • Accepting Events
    • Sending Events
  • Complexity & the Event Domain
    • Only Glue When Ok to Glue
    • When Dependency Injections is Enough
    • Interface-Based Coupling Implementation
    • De-coupling Interface-Based Coupling
    • The Challenge of Remoting
    • Moving to Messages
    • Why a Message is Preferrable
    • Strategies for Message Dispatch
    • Worrying about Payloads
    • What about Async?
    • The Huge Complexities, and Gains, of Asynchonicity
    • Implementing Asynchronous Exchange Where Possible, and Worth It
    • A Word on the Disruptor
    • Circuit Breaking for Fault Tolerance
    • Knowing what is going on, Right Now!
    • Fault Tolerance with Event Sourcing
  • Microservices
    • You’re Ready; now to Pick a Candidate Service
    • Separate codebases
    • Deploy Separately, A Test of Your De-Coupling Strateg
    • Circuit Breaking for Fault Tolerance
    • Learning to Ask, not to Shout
    • Being Reactive
    • Stoic Implementation
    • Proving the Pudding: Applying Stressors to Microservices and their Contracts
  • Simple Event-Driven Components & Functions
  • (Re)introducing the Single Responsibility Principle
    • Tangling and Scattering
    • Reduction to “Doing one thing well”
    • Reduction to Functions
    • Treating your API as a public API
    • Accepting Events
    • Sending Events
  • ManifestNO for Antifragile Software
    • Change and Ossification
    • Evil Manifestos of Years Past
    • Why a Manifesto at all?
    • Dodging the Bullet
    • Why Microservices are not just SOA
  • Remember & Apply
  • Suggested Further Reading

Read More

About the Author

The Leanpub Unconditional, No Risk, 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks. We process the refunds manually, so they may take a few days to show up.
See full terms