Slide 1

Slide 1 text

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

Slide 37

Slide 37 text

THANKS! @jpbonson 37