Software architecture, Patterns for Scale
4 likes216 views
A little bit on the part architecture has to play when we are scaling out our apps. This presentation shows a couple techniques I have proven and provides some tooling to help you get started. p.s: This is in no way exhaustive. At the architectural level, software becomes less technical and more artistic. If you know of other ways architecture helps scale, do share
![Client-Server
USES
● Web [App] Development
● Network Topologies
● Resource Sharing
Pros
● Simple
Cons
● Multiple bottlenecks](https://image.slidesharecdn.com/softwarearchitecturepatternsforscale-180304123006/85/Software-architecture-Patterns-for-Scale-22-320.jpg)
![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.](https://image.slidesharecdn.com/softwarearchitecturepatternsforscale-180304123006/85/Software-architecture-Patterns-for-Scale-34-320.jpg)
![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](https://image.slidesharecdn.com/softwarearchitecturepatternsforscale-180304123006/85/Software-architecture-Patterns-for-Scale-35-320.jpg)
Ad
More Related Content
Similar to Software architecture, Patterns for Scale (20)
Recently uploaded (20)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
Ad
Software architecture, Patterns for Scale
- 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
- 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
- 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
- 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
- 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?