Upload
eduards-sizovs
View
259
Download
1
Tags:
Embed Size (px)
Citation preview
Maslow's Hierarchy of Needs (of SoftwareDevelopment)
http://gojko.net/2012/05/08/redefining-software-quality/
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.
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
Looks familiar?✗ reveal high-level components
✗ reduce discovery cost
✗ improve comprehensibility
✗ enable poka-yoke
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.
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?)
Keep services mind-sized so there is noneed for internal layering. Break services
into tiny modules.
(and consider keeping modules in separate VCS tree)
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
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 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?
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