Strategies for Evolving Architectures, TDC Future 2021

A company's software needs are ever changing, and so the architecture must be able to keep up. This talk will present strategies to prepare and deal with this upcoming events, based both on industry references and on professional experience dealing with microservices and monoliths.

Transcript

1. Strategies for Evolving Architectures Jéssica Bonson Principal Engineer @ iFood TDC Future International, APIs and Microservices, 2021
2. 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
3. 1. What is an architecture? 2. How to evolve the architecture? 3. Refactoring Patterns Topics
4. 1 WHAT IS AN ARCHITECTURE?
5. 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
6. “ 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”
7. 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!
8. Evolutionary Architect ⬢ A software architect is like… ⬡ ...a civil architect?
9. Evolutionary Architect ⬢ A software architect is like… ⬡ ...a gardener?
10. Evolutionary Architect ⬢ A software architect is like… ⬡ ...a town planner!
11. Building zones in the game City Skylines
12. 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”
13. Promotions Recommendations Sales Easier to change Harder to change Information hiding at the microservice level
14. Promotions Recommendations Sales Easier to change Harder to change Marketing Domain Customer Domain Stock Domain Information hiding at the domain level
15. 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
16. 2 HOW TO EVOLVE THE ARCHITECTURE?
17. 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!
18. How to evolve the architecture? ⬢ An evolutionary architecture supports guided, incremental change across important characteristics
19. 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
20. ⬢ Limit the impact of errors ⬢ Learn with mistakes ⬢ Identify quick-wins ⬢ Value delivery ⬢ Understand the domain and boundaries Incremental Changes
21. “ If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang. Martin Fowler
22. Important Characteristics ⬢ Based on the business domain and goals ⬢ Use real-world data ⬡ if possible, automate ⬢ Examples ⬡ performance ⬡ code quality ⬡ reliability ⬡ operability ⬡ scalability ⬡ security
23. 3 REFACTORING PATTERNS
24. Types of Refactoring ⬢ Decomposition ⬢ Modification ⬢ Merge
25. 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
26. 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
27. Overview of the Strangler Fig Pattern
28. Example of Strangler Fig Pattern applied to a synchronous architecture
29. Example of Strangler Fig Pattern applied to an event-driven architecture
30. How to decompose? ⬢ Branch by Abstraction Pattern ⬢ A preparatory step for the Strangler Fig
31. Example applying the Branch by Abstraction Pattern
32. Handling Change between Microservices ⬢ Emulate the old interface ⬡ Use versioning ⬡ Track usage Service App Web Service App Web Service App Web
33. 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
34. 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
35. “ 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”
36. REFERENCES 36 Presentation template by SlidesCarnival
37. THANKS! @jpbonson 37