Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Architecture Evolution as Company Scales - VoxxedDays Athens 2022

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité

Consultez-les par la suite

1 sur 86 Publicité

Architecture Evolution as Company Scales - VoxxedDays Athens 2022

Télécharger pour lire hors ligne

VoxxedDays Athens 2022

In this talk, we described the technological evolution of Workable during the first decade of its life.
How the team topologies changed during this period and how the architecture was affected by these changes.

VoxxedDays Athens 2022

In this talk, we described the technological evolution of Workable during the first decade of its life.
How the team topologies changed during this period and how the architecture was affected by these changes.

Publicité
Publicité

Plus De Contenu Connexe

Plus récents (20)

Publicité

Architecture Evolution as Company Scales - VoxxedDays Athens 2022

  1. 1. Architecture Evolution as Company Scales Nikos Dimos, Kostas Zacharakis
  2. 2. Hello! Meet our speakers Nikos Dimos VP of Engineering WORKABLE Kostas Zacharakis VP of Engineering WORKABLE
  3. 3. What this talk is about?
  4. 4. OUR MISSION To make it easy for employers to find the right person for every job.
  5. 5. 26,000 COMPANIES Where great companies hire great people Since 2012, the world’s best companies have depended on Workable to find and hire the people they depend on. 1,500,000 HIRES 115,000,000 CANDIDATES 100+ COUNTRIES $84 MILLION IN FUNDING
  6. 6. 5 Generations - 3 Pillars 1G 2G 4G 2012 - 2013 2014 - 2015 2016 - 2018 2019 - 2021 2022 - 2024 3G 5G Software Infra People
  7. 7. Let's start from the beginning
  8. 8. git init ./workable
  9. 9. First Generation: The Monolith
  10. 10. In the beginning 1G - Monolith
  11. 11. In the beginning 1G - Monolith
  12. 12. In the beginning 1G - Frontend
  13. 13. In the beginning 1G - Infrastructure - PaaS
  14. 14. One codebase tracked in revision control, many deploys Explicitly declare and isolate dependencies Store config in the environment Treat backing services as attached resources Strictly separate build and run processes Execute the app as one or more stateless processes Export services via port binding Scale out via the process model Maximize robustness with fast startup and graceful shutdown Keep production, staging and production as similar as possible Treat logs as event streams Run admin or managements tasks as one-off processes The Twelve-Factor App https://12factor.net/
  15. 15. In the beginning 1G - Team topology
  16. 16. In the beginning 1G - In figures LINES OF CODE 120K In a single github repo CONTRIBUTORS 6 5 Full-Stack 🥷 engineers 1 UI Designer DEPLOYMENT 1 Single deployment in Heroku SYSTEM ENGINEERS 0 Shared responsibility between engineers
  17. 17. Experiences & Challenges
  18. 18. Small but highly engaged and productive team
  19. 19. Product evolves at very fast pace
  20. 20. Continuous…development and refactoring
  21. 21. Multiple roles and responsibilities
  22. 22. Second Generation: SPA & Satellite μServices
  23. 23. 2G - SPA & Satellite μServices Things get interesting
  24. 24. Things get interesting 2G - Frontend
  25. 25. Things get interesting 2G - Satellite μServices
  26. 26. 2G - Team Topology Things get interesting
  27. 27. Things get interesting 2G - In figures LINES OF CODE 400K ⬆233% In 5 repos CONTRIBUTORS 19 ⬆250% 9 Backend Engineers 4 Frontend Engineers 2 UI Designers 3 ML Engineers 1 Test Engineer DEPLOYMENT 4 Deployments in Heroku SYSTEM ENGINEERS 0 Shared responsibility between engineers
  28. 28. Experiences & Challenges
  29. 29. 2 pizzas are not enough
  30. 30. Lack of automation
  31. 31. Low release confidence
  32. 32. Hello Node.js!
  33. 33. Third Generation: Beyond the Monolith
  34. 34. 3G - Beyond the monolith Things get tricky
  35. 35. Beyond the monolith 3G - Frontend
  36. 36. Beyond the monolith 3G - (μ)Services
  37. 37. Beyond the monolith Self-hosted Infrastructure
  38. 38. 3G - Team Structure Beyond the monolith
  39. 39. Beyond the monolith 3G - Figures LINES OF CODE 1.6M ⬆300% In 25 repos CONTRIBUTORS 51 ⬆250% 19 Backend Engineers 17 Frontend Engineers 8 UI Designers 9 ML Engineers 5 Mobile Engineers 2 Test Engineers 1 Security Engineer DEPLOYMENTS 25 ⬆525% Deployments in AWS SITE RELIABILITY ENGINEERS 4 In-house provisioning tools for AWS
  40. 40. Experiences & Challenges
  41. 41. Increased productivity
  42. 42. Disjointed visual identity
  43. 43. Strong coupling between services
  44. 44. State sharing across services
  45. 45. Transition to AWS
  46. 46. Fourth Generation: Event Sourcing & Design System
  47. 47. Things getting decoupled 4G - Event Sourcing
  48. 48. Design System 4G - Atomic Design Design System Product https://atomicdesign.bradfrost.com/
  49. 49. Atomic Design Design System - Atoms
  50. 50. Atomic Design Design System - Molecules
  51. 51. Atomic Design Design System - Organisms
  52. 52. Design System Components in action
  53. 53. Beyond the monolith Self-hosted Infrastructure - Season 2
  54. 54. Fourth Generation 4G - Team topology
  55. 55. Things get interesting 4G - Figures LINES OF CODE 3M ⬆150% In 48 repos CONTRIBUTORS 84 ⬆71% 31 Backend Engineers 30 Frontend Engineers 10 Mobile Engineers 5 UI Designers 10 ML Engineers 5 Test Engineers 2 Security Engineers DEPLOYMENTS 50 SITE RELIABILITY ENGINEERS 9 Kubernetes in GCP ⬆100% Deployments in GCP
  56. 56. Experiences & Challenges
  57. 57. Tailwind direction with Kubernetes
  58. 58. Development experience In legacy code
  59. 59. Increased time to deliver
  60. 60. Fifth Generation: Rethinking the monolith(s)
  61. 61. Improve Dev XP 5G - Frontend Monolith
  62. 62. Improve Dev XP 5G - μFronteds
  63. 63. 5G - μFrontends Module Federation
  64. 64. What about the legacy code?
  65. 65. Strangler Pattern Incremental Upgrades
  66. 66. Strangler Pattern Transform
  67. 67. Strangler Pattern Coexist
  68. 68. Strangler Pattern Eliminate
  69. 69. To summarize
  70. 70. Architecture evolution in 5 gens 1G - Monolith 2012 - 2013 2014 - 2015 2016 - 2018 2019 - 2021 2022 - 2024 2G - Satellite Services 3G - beyond the monolith 4G - Event Sourcing & Design System 5G - rethinking Monoliths
  71. 71. Team structures evolution 2012 - 2013 2014 - 2015 2016 - 2018 2019 - 2021 2022 - 2024
  72. 72. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Melvin E. Conway Computer scientist
  73. 73. “If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”
  74. 74. Team dimensions
  75. 75. Team Size Four Dimensions in Designing Team Structures PERSONAL RELATIONSHIPS 5 DEEP TRUST MUTUAL TRUST 50 REMEMBER CAPABILITIES 150 15
  76. 76. Team Lifespan Four Dimensions in Designing Team Structures Forming Norming Storming Performing
  77. 77. Team Ownership Four Dimensions in Designing Team Structures “Every software system should have exactly one owner”
  78. 78. Team Cognition Four Dimensions in Designing Team Structures
  79. 79. ● Language ● Framework ● Code design pattern
  80. 80. ● Deployment tools ● Configuration tools ● Interactions with other teams
  81. 81. ● Business Logic ● High Throughput Systems ● Distributed Systems
  82. 82. One size doesn’t fit all
  83. 83. Thank you!
  84. 84. Enough about us. We're more interested in you. Talent sourcing is in our blood, so if you're bright, bold and after more than just a job, get in touch. We look forward to meeting you. Explore at https://careers.workable.com Join us

×