software architecture anti-patterns
TRANSCRIPT
YAGNI Architecture
Story time
Some software is never intended to standout from the crowd.
YAGNI KIND ASS Architecture
KEEP IT NEED DRIVEN AND SIMPLE, SIR
NEED-DRIVEN ?
NEED-DRIVEN ?
REQUIREMENTS
NEED-DRIVEN ?
REQUIREMENTS • RISKS
NEED-DRIVEN ?
REQUIREMENTS • RISKS • CONSTRAINTS
Maslow's Hierarchy of Needs (of SoftwareDevelopment)
http://gojko.net/2012/05/08/redefining-software-quality/
SIMPLE ?
Pick the tool you know well and ship thesimplest possible solution.
Optimize for CHANGE.
Nano-Service Architecture
When SOA goes wild.
You think that because you understand “one” thatyou must therefore understand “two” because one
and one make two. But you forget that you must alsounderstand “and.”
— Sufi teaching story
By blindly splitting a system into "micro" services, youget all negative consequences with questionable
benefits.
Micro Service-Oriented Architecture
SIZE DOESN'T MATTER
Driving factors for decomposition
Driving factors for decomposition
- Team boundaries
Driving factors for decomposition
- Team boundaries
- Frequency of change
Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack
Driving factors for decomposition
- Team boundaries
- Frequency of change
- Different responsibilities
- Different (cross-functional) requirements
- Different technical stack
- Prototyping / Experiments
Staying BIG is OK.
Structureless Architecture
Looks familiar?
Looks familiar?✗ reveal high-level components
Looks familiar?✗ reveal high-level components
✗ reduce discovery cost
Looks familiar?✗ reveal high-level components
✗ reduce discovery cost
✗ improve comprehensibility
Looks familiar?✗ reveal high-level components
✗ reduce discovery cost
✗ improve comprehensibility
✗ enable poka-yoke
What about this?
What about this?✔ reveal high-level components
What about this?✔ reveal high-level components
✔ reduce discovery cost
What about this?✔ reveal high-level components
✔ reduce discovery cost
✔ improve comprehensibility
What about this?✔ reveal high-level components
✔ reduce discovery cost
✔ improve comprehensibility
✔ enable poka-yoke
Apply micro service-oriented mindset to softwarestructure. Keep services decoupled as if they were
remote.
WHERE IS LAYERING?
Lasagna Architecture
Expected (doubtful) benefits from layering
Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
Expected (doubtful) benefits from layering
- Ability to distribute your layers over multiple physical tiers (ha-ha)
- Decoupling / abstracting for exhangeability (ha-ha)
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)
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)
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?)
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?)
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?)
Layering is your service's detail and isinternal to the service.
Keep services mind-sized so there is noneed for internal layering. Break services
into tiny modules.
(and consider keeping modules in separate VCS tree)
Undocumented Architecture
Working software over comprehensivedocumentation.
(c) Agile Manifesto
Architecture is code!
...but level of abstraction of code is negligible
I remember everything!
Code has hard time telling you about
Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
Code has hard time telling you about
- Backups, Disaster Recovery, Redundancy, Failover, ETL, SLA, etc.
- Significant Decisions and Agreements (e.g. rejected frameworks)
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)
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)
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
"That’s the page I read that made thedifference"
is a great sanity check
UML vs C4
Context, Containers, Components, Classes
Optimistic Architecture
Fault tolerance is a lesson best learned offline.
Raise and keep your hand if you know ->
Raise and keep your hand if you know ->
What connection and thread pools does your application have
Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Raise and keep your hand if you know ->
What connection and thread pools does your application have
Approximate size
Utilization during peak load
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
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
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
What if an integration point will start to fail?
What if an integration point will start to fail?
What if it will send slow response for 5+ minutes without failing?
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?
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?
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 applandscape?
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 applandscape?
Can you switch off functionality that produces unexpectedly highload?
Timeouts
Timeouts
Retries
Timeouts
Retries
Circuit Breakers
Timeouts
Retries
Circuit Breakers
Bulkheads
Timeouts
Retries
Circuit Breakers
Bulkheads
Handshaking
Timeouts
Retries
Circuit Breakers
Bulkheads
Handshaking
Leaky Bucket
...
Alchemy Architecture
Wear software architect's hat byunderstanding and impacting current state
of affairs.
Run short design sessions before diving intoimplementation.
Make sure architecture is VISIBLE foreveryone.
Run weekly meetup on issues and plan howto get better in small steps.
Change the architecture with baby steps
Change the architecture with baby steps
~ 45 minutes a day / person
Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
Change the architecture with baby steps
~ 45 minutes a day / person
~ 4 hours a week / person
~ 20 hours a week / 5 people
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.
Software Architecture Essentials
11th of March, 2015
Register at www.craftsmans.lv
