An evolutionary architecture supports incremental, guided change across multiple dimensions.
For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on our recent book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; we describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; we cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; we cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.
The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This talk illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.
22. guided
evolutionary computing fitness function:
a particular type of objective function that is
used to summarize…how close a given design
solution is to achieving the set aims.
24. guided
evolutionary computing fitness function:
a particular type of objective function that is
used to summarize…how close a given design
solution is to achieving the set aims.
90. Mechanics
1. Identify dimensions affect by evolution
2. Define Fitness Function(s) for Each Dimension
3. Use Deployment Pipelines to Automate Fitness Functions
92. Mechanics
1. Identify dimensions affect by evolution
2. Define Fitness Function(s) for Each Dimension
3. Use Deployment Pipelines to Automate Fitness Functions
93. Mechanics
1. Identify dimensions affect by evolution
2. Define Fitness Function(s) for Each Dimension
3. Use Deployment Pipelines to Automate Fitness Functions
97. ▫ It decides whether or not to run the try block,
▫ Randomizes the order in which use and try blocks are
run,
▫ Measures the durations of all behaviors,
▫ Compares the result of try to the result of use,
▫ Swallows (but records) any exceptions raised in the try
block
▫ Publishes all this information.
98.
99.
100.
101. 4 days
24 hours/
no mismatches or slow cases
> 10,000,000
comparisons
> 10,000,000
comparisons
For example, a company that handles international fund transfers
might design a specific, continuous, holistic fitness function that stress tests security,
modeled after the way that the Simian Army (covered in Chapter 3) stresses infrastructure.
Unit test to verify architectural integrity
Examples
Integration tests to ensure proper co-evolution
Security and scaling interaction
endpoint testing
Balancing and tradeoffs
Accordion: Radiolab & foxes
Neal
Rebecca
PAT
A lot of teams don’t identify what they are building the architecture for. It doesn’t take long to identify which ones are relevant.
Domain = finance, banking, retail, entertainment
Define how you know you are done. DoD for each dimension (fuzzier, not so clear)
Examples:
Add in performance testing pipelines (memory leak) - even a simple smaller constrained
Security, modularity checks
Chaos engineering - testing the holistic fitness functions
Shortly after the deploy, the accuracy graph shows that experiments are being run at the right frequency and that mismatches are very few.
Graphing the errors/mismatches on their own shows their frequency in more detail. Our tooling captures metadata all these mismatches so they can be analyzed later.
Although it's too early to tell, shortly after the initial deploy the performance characteristics look extremely promising. The vertical axis is time, in milliseonds. Percentiles for the old and new code are shown in blue and green, respectively.