Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Strategies for Evolving Architectures, TDC Fut...

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.

Jessica Pauli de C Bonson

December 02, 2021
Tweet

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

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. 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
  5. “ 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”
  6. 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!
  7. 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”
  8. Promotions Recommendations Sales Easier to change Harder to change Marketing

    Domain Customer Domain Stock Domain Information hiding at the domain level
  9. 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
  10. 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!
  11. How to evolve the architecture? ⬢ An evolutionary architecture supports

    guided, incremental change across important characteristics
  12. 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
  13. ⬢ Limit the impact of errors ⬢ Learn with mistakes

    ⬢ Identify quick-wins ⬢ Value delivery ⬢ Understand the domain and boundaries Incremental Changes
  14. “ If you do a big-bang rewrite, the only thing

    you’re guaranteed of is a big bang. Martin Fowler
  15. Important Characteristics ⬢ Based on the business domain and goals

    ⬢ Use real-world data ⬡ if possible, automate ⬢ Examples ⬡ performance ⬡ code quality ⬡ reliability ⬡ operability ⬡ scalability ⬡ security
  16. 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
  17. 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
  18. How to decompose? ⬢ Branch by Abstraction Pattern ⬢ A

    preparatory step for the Strangler Fig
  19. Handling Change between Microservices ⬢ Emulate the old interface ⬡

    Use versioning ⬡ Track usage Service App Web Service App Web Service App Web
  20. 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
  21. 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
  22. “ 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”