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!
-
Installments completed
- 5 / 17
-
Feedback
Share this book
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
About the Author
Russ Miles is Chief Scientist at Simplicity Itself where he works with his clients to help deliver simple and valuable software and change.
Russ' experience covers almost every facet of software delivery having worked across many different domains including Financial Services, Publishing, Defence, Insurance and Search.
Russ helps to change all facets of the software delivery process in order to remove unnecessary and costly complexity in everything from developer skills and practices, through applying the right processes for the job at hand, to ensuring that the right change is delivered, be it through software or otherwise.
Passionate about open source software, Russ worked with SpringSource prior to the company's acquisition by VMware, leading the Spring Extensions project and helping international clients to simplify their software by effectively applying the Spring portfolio of projects.