Strategies for
Evolving
Architectures
Jéssica Bonson
Principal Engineer @ iFood TDC Future International, APIs and Microservices, 2021
Slide 2
Slide 2 text
HELLO!
I am Jéssica Bonson (@jpbonson)
Principal Engineer @ iFood
2
⬢ Bachelors/Masters in Computer Science
⬢ 9+ years of experience in many projects and techstacks
Slide 3
Slide 3 text
1. What is an architecture?
2. How to evolve the
architecture?
3. Refactoring Patterns
Topics
Slide 4
Slide 4 text
1 WHAT IS AN
ARCHITECTURE?
Slide 5
Slide 5 text
Software Architecture
⬢ The architecture is not a never-changing artifact
⬡ Don’t try to create a perfect end product
⬢ Plan to allow for change
⬢ Create a framework in which the right systems
can emerge and grow as we learn more
Slide 6
Slide 6 text
“
There is danger that people will
see the need to rearchitect
when certain scaling thresholds
are reached as a reason to build
for massive scale from the
beginning. This can be
disastrous.
“Building Microservices”
Slide 7
Slide 7 text
Software Architecture
⬢ At the start of a new project we…
⬡ don’t know exactly what we want to build
⬡ don’t know if it will be successful
⬡ need to be able to rapidly experiment
and understand what we need to build
The need to change our systems to deal with
scale isn’t a sign of failure, but of success!
Slide 8
Slide 8 text
Evolutionary Architect
⬢ A software architect is like…
⬡ ...a civil architect?
Slide 9
Slide 9 text
Evolutionary Architect
⬢ A software architect is like…
⬡ ...a gardener?
Slide 10
Slide 10 text
Evolutionary Architect
⬢ A software architect is like…
⬡ ...a town planner!
Slide 11
Slide 11 text
Building zones in the game City Skylines
Slide 12
Slide 12 text
Evolutionary Architect
⬢ Define spaces in which changes can be
made without compromising the system
⬡ make developers’ lives easier
⬢ Information hiding
⬡ both at the microservice level, and at the team level
“Be worried about what happens between the
boxes, and be liberal at what happens inside”
Slide 13
Slide 13 text
Promotions Recommendations
Sales
Easier to change
Harder to change
Information hiding at the microservice level
Slide 14
Slide 14 text
Promotions Recommendations
Sales
Easier to
change
Harder to change
Marketing Domain
Customer Domain
Stock Domain
Information hiding at the domain level
Slide 15
Slide 15 text
Evolutionary Architecture
⬢ A successful architecture:
⬡ Allow for change
⬡ “Habitability”
⬡ The environment created is nice to work in for the devs
⬡ DDD (Domain-Driven Design)
⬡ Modularity
⬡ High cohesion, low coupling
Slide 16
Slide 16 text
2 HOW TO EVOLVE THE
ARCHITECTURE?
Slide 17
Slide 17 text
Why evolve the architecture?
⬢ Despite our best efforts, software becomes
harder to change over time
⬢ Since we can’t avoid change, we need to
exploit it
⬡ We must learn to adapt!
Slide 18
Slide 18 text
How to evolve the architecture?
⬢ An evolutionary architecture supports
guided, incremental change across
important characteristics
Slide 19
Slide 19 text
Fitness Functions
⬢ The relative ‘fitness’ of the architecture to the
principles and constraints
⬡ Evaluate the impact of the changes
⬡ Prevent degradation
⬢ Guides decision making
⬢ Defined with the people building the system
Slide 20
Slide 20 text
⬢ Limit the impact of errors
⬢ Learn with mistakes
⬢ Identify quick-wins
⬢ Value delivery
⬢ Understand the domain and boundaries
Incremental Changes
Slide 21
Slide 21 text
“
If you do a big-bang rewrite,
the only thing you’re
guaranteed of is a big bang.
Martin Fowler
Slide 22
Slide 22 text
Important Characteristics
⬢ Based on the business domain and goals
⬢ Use real-world data
⬡ if possible, automate
⬢ Examples
⬡ performance
⬡ code quality
⬡ reliability
⬡ operability
⬡ scalability
⬡ security
Slide 23
Slide 23 text
3 REFACTORING
PATTERNS
Slide 24
Slide 24 text
Types of Refactoring
⬢ Decomposition
⬢ Modification
⬢ Merge
Slide 25
Slide 25 text
What to decompose first?
⬢ Why?
⬡ Scale? Look for the bottleneck
⬡ Time to market? Look for volatility
⬡ Complexity? Look for domains
⬢ Difficulty vs Benefit of the extraction
Slide 26
Slide 26 text
How to decompose?
⬢ Strangler Fig Pattern
“Gradually create a new system around the edges of the old, letting it grow
slowly over several years until the old system is strangled.”, Martin Fowler
Slide 27
Slide 27 text
Overview of the Strangler Fig Pattern
Slide 28
Slide 28 text
Example of Strangler Fig Pattern applied to a synchronous architecture
Slide 29
Slide 29 text
Example of Strangler Fig Pattern applied to an event-driven architecture
Slide 30
Slide 30 text
How to decompose?
⬢ Branch by Abstraction Pattern
⬢ A preparatory step for the Strangler Fig
Slide 31
Slide 31 text
Example applying the Branch by Abstraction Pattern
Slide 32
Slide 32 text
Handling Change between Microservices
⬢ Emulate the old interface
⬡ Use versioning
⬡ Track usage
Service
App Web
Service
App Web
Service
App Web
Slide 33
Slide 33 text
Handling Change between Microservices
⬢ Emulate the old interface
⬡ Use versioning
⬡ Track usage
Service
App Web
Service
App Web
Service
App Web
Service
App Web
Optional Step
Slide 34
Slide 34 text
Handling Change between Microservices
⬢ Expand-Contract Pattern
⬡ Example: Rename field A to B
i. Add field B, without using it
ii. Write both in A and in B
iii. Only read B
iv. Remove A (optional)
34
Slide 35
Slide 35 text
“
Architecture is what happens,
not what is planned. If as an
architect you remove yourself
from the process of putting this
vision into place, then you are
not an architect, you are a
dreamer.
“Building Microservices”
Slide 36
Slide 36 text
REFERENCES
36
Presentation template by SlidesCarnival