Software_Architecture_Patterns_for_Scale.pdf

Transcript

1. Patterns for Scale Software Architecture
2. @igbanam • Senior Consultant @ Andela • Ruby Aficionado • Poet • Gym Rat • Anime Lover
3. Why do we scale?
4. Why do we scale? Our application proves brittle
5. How to scale in a nutshell cube
6. Scaling Twitter Good • MVP to “Success” really fast • Rails prototyping power Bad • One tool mindset • Y-axis Scaling Lessons • Scale apps with people • Sometimes overhaul is good
7. Scaling Shopify Good • Optimization • Sharding Bad • Originally did not understand the market — ”Flash Sales” Lessons • When scaling, do one thing at a time.
8. Scaling IASD Good • Performance Benchmarking Bad • Windows Home Server • Government Project Lessons • Measure your performance • Layer your deployment
9. Scaling Why is it hard? Reasons • Amdahl’s Law vs Moore’s Law • Business Constraints • Resource Constraints • Developer KPIs
10. Does Architecture Matter?
11. 100% YES
12. What is Software Architecture? The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural. ~ Wikipedia
13. What is Software Architecture? In OOP, your class is the blueprint for an object at runtime. Similar to the architecture of your solution, it is the blueprint of your solution during its lifetime. One should be able to look at your architecture and immediately see the system built, the same way your classes should be self-explanatory. ~ @igbanam
14. What is Software Architecture? Guess the system
15. What is Software Architecture? Guess the system
16. Architectural Patterns
17. Layered How we build • Contained Layers • Separation of Concerns
18. Layered Read “Clean Architecture” by Robert Martin (a.k.a Uncle Bob)
19. Layered Architecture USES • Model - View - Controller • Web Applications • Operating Systems Pros • Separation of concerns Cons • One tool fixes all • Often misused
20. Client–Server Microservices, SOA, Peer-to-Peer • Client makes all the requests • Server is a black box of processing
21. Client-Server
22. Client-Server USES • Web [App] Development • Network Topologies • Resource Sharing Pros • Simple Cons • Multiple bottlenecks
23. Event–Driven Park the bus! • Channels on a “bus” • Publish - Subscribe • “Fire and Forget”
24. Event Driven
25. Event Driven USES • Messaging Systems • Notifiers Pros • Resilient Cons • Orchestration is difficult • New skill required
26. Broker Delegator • Thin Master • Orchestrator • Manager
27. Broker
28. Broker USES • Load Balancing • Expert Systems Pros • Orchestration • Transparency • Interoperability — Broker of Brokers or P2P Cons • Lower fault tolerance • Restricted efficiency • Potential security hazard
29. Scaling Methodologies
30. Things to Scale • The development team • Your application
31. Scaling your development team Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. ~ Conway’s Law
32. Scaling your development team • Agile Methods: XP, DSDM, Scrum, Scrumban, Kanban, Lean, … • Scrum of scrums • Ubiquitous Language
33. Scrum PROS • Holds developers accountable • Ceremonies which do health check on teams • Opens the development processes up to the business CONS • Ceremonies can become a bore — switch it up: Scrumban • The development team could become an assembly line
34. Scaling your Application • Focus on the domain ◦ Focus on the “Domain” ◦ Bounded Contexts ▪ Islands (Independent Clusters) would begin to form in your models. • Code like an elite ◦ Structural Design Patterns ◦ Behavioural Design Patterns ◦ Creational Design Patterns ◦ SOLID, KISS, DRY • In Deployment ◦ More computing power — Moore’s Law vs. Amdahl’s Law [ | ] ◦ More computers — [ - ] ◦ More computes — [ \ ] Sharding. Breaking up similar things into inherent groups.
35. Bounded Contexts 1. Focus on data and structure. 2. Print out the domain’s ERD. 3. Encircle similar entities. 4. Group these circles in code as modules (or folders) 5. [Optional] Define a facade for each module. 6. Transition module to service. 7. Scale. The Journey into Microservices
36. Message Queues 1. Focus on communication. 2. Set up a message bus. In monolith, consider “observers” 3. Emit events for key actions 4. Subscribers should handle post-processing in parallel 5. Employ efficient brokers. 6. Scale underlying workers/subscribers. The Journey into Events
37. Scaling your Deployment
38. Scaling your Deployment
39. Scaling your Deployment
40. Scaling Your Deployment • Multiple application servers • Multiple database servers • Broker Balancer Furthermore… • The application servers should be cached • The database access should serve as a cache.
41. Tooling
42. Conclusion • Try to see beyond the problem you’re trying to solve into the problem your solution creates; then solve that problem • The architect does not design for the codebase; that’s the job of the software designer. The architect designs the domain and her systems • Measure EVERYTHING!!! • Scale forward
43. Questions?