Applications of different size, business domain and criticality suffer from a huge set of issues, be it boring enterprise software, “Highly-Loaded” social network or a cozy startup. In this talk Eduards will cover Software Architecture issues that he finds the most prevailing nowadays and what you can do with that. Think big!
16. You think that because you understand “one” that
you must therefore understand “two” because one
and one make two. But you forget that you must also
understand “and.”
— Sufi teaching story
17. By blindly splitting a system into "micro" services, you
get all negative consequences with questionable
benefits.
22. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
23. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
24. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack
25. Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack
- Prototyping / Experiments
42. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
43. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
44. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
45. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
46. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)
47. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)
- Related stuff co-location (are DAOs really related?)
48. Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
- Decoupling / abstracting for independent evolution (ha-ha)
- Decoupling for reuse (ha-ha)
- Separation of concerns (is particular layer our concern?)
- Related stuff co-location (are DAOs really related?)
- Constraint enforcement (is there a better way?)
49. Layering is your service's detail and is
internal to the service.
50. Keep services mind-sized so there is no
need for internal layering. Break services
into tiny modules.
(and consider keeping modules in separate VCS tree)
56. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
57. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
58. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)
59. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)
- Onboarding (Source Repository, Building, QC, Deployment)
60. Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
- Surroundings (Dependencies, Service Consumers)
- Onboarding (Source Repository, Building, QC, Deployment)
- Birdseye Technical View
61. "That’s the page I read that made the
difference"
is a great sanity check
62. UML vs C4
Context, Containers, Components, Classes
67. Raise and keep your hand if you know ->
What connection and thread pools does your application have
68. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
69. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
70. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit
71. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit
How does your app behave when pools become full
72. Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
When pools will approach the size limit
How does your app behave when pools become full
How to timely react on it
73.
74. What if an integration point will start to fail?
75. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
76. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
77. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?
78. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?
If your service fails, how far that failure reaches into app
landscape?
79. What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
What if it will send back huge 1GB result set?
If your service fails, can others handle additional load they take?
If your service fails, how far that failure reaches into app
landscape?
Can you switch off functionality that produces unexpectedly high
load?
95. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
96. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
~ 20 hours a week / 5 people
97. Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
~ 20 hours a week / 5 people
No excuse for not starting tomorrow.