Maslow's Hierarchy of Needs (of Software Development)
http://gojko.net/2012/05/08/redefining-software-quality/
Tiny by Chad Fowler
http://www.infoq.com/presentations/small-iteration-method-team
Making Badass Developer by Kathy Sierra
https://www.youtube.com/watch?v=FKTxC9pl-WM
You think that because you understand “one” that you must thereforeunderstand “two” because one and one make two. But you forget that you
must also understand “and.”
— Sufi teaching story
By blindly splitting a system into "micro" services, you get all negativeconsequences 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 software structure. Keep servicesdecoupled 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 no need for internallayering. 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 app landscape?
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?